[jira] [Commented] (IGNITE-8869) PartitionsExchangeOnDiscoveryHistoryOverflowTest hangs on TeamCity
[ https://issues.apache.org/jira/browse/IGNITE-8869?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16536754#comment-16536754 ] Ivan Daschinskiy commented on IGNITE-8869: -- [~v.pyatkov] [~agura] Guys, I'm sorry but I've forgotten to exclude daemon nodes from filter. This can possible cause hang of the grid. I've corrected this mistake and made TC run again. Could you please review and merge this little patch? > PartitionsExchangeOnDiscoveryHistoryOverflowTest hangs on TeamCity > -- > > Key: IGNITE-8869 > URL: https://issues.apache.org/jira/browse/IGNITE-8869 > Project: Ignite > Issue Type: Bug >Affects Versions: 2.5 >Reporter: Ivan Daschinskiy >Assignee: Ivan Daschinskiy >Priority: Critical > Labels: MakeTeamcityGreenAgain > Fix For: 2.7 > > > After introduction of ExhangeLatches, > PartitionsExchangeOnDiscoveryHistoryOverflowTest will hangs permanently. In > current implementation, ExchangeLatchManager retrieves alive nodes from > discoveryCache with specific affinity topology version and fails because of a > too short discovery history. This causes fail of exchange-worker and > therefore NoOpFailureHandler leaves node in hanging state. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-8745) Add ability to monitor TCP discovery ring information
[ https://issues.apache.org/jira/browse/IGNITE-8745?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16534962#comment-16534962 ] Ivan Daschinskiy commented on IGNITE-8745: -- [~ezagumennov] Ok, now its looks good for me. I think that you fix is ready for merge. Thanks for contribution. > Add ability to monitor TCP discovery ring information > - > > Key: IGNITE-8745 > URL: https://issues.apache.org/jira/browse/IGNITE-8745 > Project: Ignite > Issue Type: Improvement >Reporter: Alexey Goncharuk >Assignee: Evgenii Zagumennov >Priority: Major > Time Spent: 16h > Remaining Estimate: 0h > > We should add the following modifications: > 1) Add a method on TCP discovery MBean to dump the ring structure on local > node and on all nodes in the grid > 2) Make tcp-disco-worker thread name reflect the node to which the local node > is connected > 3) Add a method on TCP discovery MBean to return current topology version -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-8945) Stored cache data files corruption when node stops abruptly.
Ivan Daschinskiy created IGNITE-8945: Summary: Stored cache data files corruption when node stops abruptly. Key: IGNITE-8945 URL: https://issues.apache.org/jira/browse/IGNITE-8945 Project: Ignite Issue Type: Bug Affects Versions: 2.5 Reporter: Ivan Daschinskiy Assignee: Ivan Daschinskiy Fix For: 2.7 When node is halted during saving stored cache data, content of this file can be corrupted. 1. Additional check should be implemented in FilePageStoreManager.readCacheData (print the name of corrupted file) 2. In storeCacheData we need to serialize StoredCacheData to temp file then swap. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Comment Edited] (IGNITE-8620) Remove intOrder and loc keys from node info in control.sh --tx utility
[ https://issues.apache.org/jira/browse/IGNITE-8620?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16533498#comment-16533498 ] Ivan Daschinskiy edited comment on IGNITE-8620 at 7/5/18 10:39 AM: --- [~a-polyakov], [~ascherbakov] This fix looks good to me. was (Author: ivandasch): [~a-polyakov][~ascherbakov] This fix looks good to me. > Remove intOrder and loc keys from node info in control.sh --tx utility > -- > > Key: IGNITE-8620 > URL: https://issues.apache.org/jira/browse/IGNITE-8620 > Project: Ignite > Issue Type: Improvement >Reporter: Dmitry Sherstobitov >Assignee: Alexand Polyakov >Priority: Major > > For now this information displayed in control.sh utility for each node: > TcpDiscoveryNode [id=2ed402d5-b5a7-4ade-a77a-12c2feea95ec, > addrs=[0:0:0:0:0:0:0:1%lo, 127.0.0.1, 172.25.1.47], > sockAddrs=[/0:0:0:0:0:0:0:1%lo:0, /127.0.0.1:0, /172.25.1.47:0], discPort=0, > order=6, intOrder=6, lastExchangeTime=1526482701193, loc=false, > ver=2.5.1#20180510-sha1:ee417b82, isClient=true] > loc and intOrder values are internal information and there is not need to > display it > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-8620) Remove intOrder and loc keys from node info in control.sh --tx utility
[ https://issues.apache.org/jira/browse/IGNITE-8620?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16533498#comment-16533498 ] Ivan Daschinskiy commented on IGNITE-8620: -- [~a-polyakov][~ascherbakov] This fix looks good to me. > Remove intOrder and loc keys from node info in control.sh --tx utility > -- > > Key: IGNITE-8620 > URL: https://issues.apache.org/jira/browse/IGNITE-8620 > Project: Ignite > Issue Type: Improvement >Reporter: Dmitry Sherstobitov >Assignee: Alexand Polyakov >Priority: Major > > For now this information displayed in control.sh utility for each node: > TcpDiscoveryNode [id=2ed402d5-b5a7-4ade-a77a-12c2feea95ec, > addrs=[0:0:0:0:0:0:0:1%lo, 127.0.0.1, 172.25.1.47], > sockAddrs=[/0:0:0:0:0:0:0:1%lo:0, /127.0.0.1:0, /172.25.1.47:0], discPort=0, > order=6, intOrder=6, lastExchangeTime=1526482701193, loc=false, > ver=2.5.1#20180510-sha1:ee417b82, isClient=true] > loc and intOrder values are internal information and there is not need to > display it > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-8745) Add ability to monitor TCP discovery ring information
[ https://issues.apache.org/jira/browse/IGNITE-8745?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16533494#comment-16533494 ] Ivan Daschinskiy commented on IGNITE-8745: -- [~ezagumennov] Hi! I've looked over your changes. I have several remarks and I added some comments in your github PR. Also, there is no tests. You should ad test to TcpDiscoverySpiSelfTest and tests that your MBean attributes works. Also, TC run should be attached. > Add ability to monitor TCP discovery ring information > - > > Key: IGNITE-8745 > URL: https://issues.apache.org/jira/browse/IGNITE-8745 > Project: Ignite > Issue Type: Improvement >Reporter: Alexey Goncharuk >Assignee: Evgenii Zagumennov >Priority: Major > Time Spent: 16h > Remaining Estimate: 0h > > We should add the following modifications: > 1) Add a method on TCP discovery MBean to dump the ring structure on local > node and on all nodes in the grid > 2) Make tcp-disco-worker thread name reflect the node to which the local node > is connected > 3) Add a method on TCP discovery MBean to return current topology version -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-8920) Node should be failed when during tx finish indices are corrupted.
Ivan Daschinskiy created IGNITE-8920: Summary: Node should be failed when during tx finish indices are corrupted. Key: IGNITE-8920 URL: https://issues.apache.org/jira/browse/IGNITE-8920 Project: Ignite Issue Type: Bug Affects Versions: 2.5 Reporter: Ivan Daschinskiy Fix For: 2.7 While transaction is processed after receiving finish request (IgniteTxHandler.finish) , node should be failed by FailureHandler if page content of indices is corrupted. Currently this case is not handled properly and cause to long running transactions over the grid. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Assigned] (IGNITE-8869) PartitionsExchangeOnDiscoveryHistoryOverflowTest hangs on TeamCity
[ https://issues.apache.org/jira/browse/IGNITE-8869?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ivan Daschinskiy reassigned IGNITE-8869: Assignee: Ivan Daschinskiy > PartitionsExchangeOnDiscoveryHistoryOverflowTest hangs on TeamCity > -- > > Key: IGNITE-8869 > URL: https://issues.apache.org/jira/browse/IGNITE-8869 > Project: Ignite > Issue Type: Bug >Affects Versions: 2.5 >Reporter: Ivan Daschinskiy >Assignee: Ivan Daschinskiy >Priority: Critical > Labels: MakeTeamcityGreenAgain > Fix For: 2.7 > > > After introduction of ExhangeLatches, > PartitionsExchangeOnDiscoveryHistoryOverflowTest will hangs permanently. In > current implementation, ExchangeLatchManager retrieves alive nodes from > discoveryCache with specific affinity topology version and fails because of a > too short discovery history. This causes fail of exchange-worker and > therefore NoOpFailureHandler leaves node in hanging state. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-8869) PartitionsExchangeOnDiscoveryHistoryOverflowTest hangs on TeamCity
[ https://issues.apache.org/jira/browse/IGNITE-8869?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ivan Daschinskiy updated IGNITE-8869: - Summary: PartitionsExchangeOnDiscoveryHistoryOverflowTest hangs on TeamCity (was: PartitionsExchangeOnDiscoveryHistoryOverflowTest fails permanently) > PartitionsExchangeOnDiscoveryHistoryOverflowTest hangs on TeamCity > -- > > Key: IGNITE-8869 > URL: https://issues.apache.org/jira/browse/IGNITE-8869 > Project: Ignite > Issue Type: Bug >Affects Versions: 2.5 >Reporter: Ivan Daschinskiy >Priority: Major > Labels: MakeTeamcityGreenAgain > Fix For: 2.6 > > > After introduction of ExhangeLatches, > PartitionsExchangeOnDiscoveryHistoryOverflowTest will hangs permanently. In > current implementation, ExchangeLatchManager retrieves alive nodes from > discoveryCache with specific affinity topology version and fails because of a > too short discovery history. This causes fail of exchange-worker and > therefore NoOpFailureHandler leaves node in hanging state. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-8869) PartitionsExchangeOnDiscoveryHistoryOverflowTest
Ivan Daschinskiy created IGNITE-8869: Summary: PartitionsExchangeOnDiscoveryHistoryOverflowTest Key: IGNITE-8869 URL: https://issues.apache.org/jira/browse/IGNITE-8869 Project: Ignite Issue Type: Bug Affects Versions: 2.5 Reporter: Ivan Daschinskiy Fix For: 2.6 After introduction of ExhangeLatches, PartitionsExchangeOnDiscoveryHistoryOverflowTest will hangs permanently. In current implementation, ExchangeLatchManager retrieves alive nodes from discoveryCache with specific affinity topology version and fails because of a too short discovery history. This causes fail of exchange-worker and therefore NoOpFailureHandler leaves node in hanging state. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-8869) PartitionsExchangeOnDiscoveryHistoryOverflowTest fails permanently
[ https://issues.apache.org/jira/browse/IGNITE-8869?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ivan Daschinskiy updated IGNITE-8869: - Summary: PartitionsExchangeOnDiscoveryHistoryOverflowTest fails permanently (was: PartitionsExchangeOnDiscoveryHistoryOverflowTest ) > PartitionsExchangeOnDiscoveryHistoryOverflowTest fails permanently > -- > > Key: IGNITE-8869 > URL: https://issues.apache.org/jira/browse/IGNITE-8869 > Project: Ignite > Issue Type: Bug >Affects Versions: 2.5 >Reporter: Ivan Daschinskiy >Priority: Major > Labels: MakeTeamcityGreenAgain > Fix For: 2.6 > > > After introduction of ExhangeLatches, > PartitionsExchangeOnDiscoveryHistoryOverflowTest will hangs permanently. In > current implementation, ExchangeLatchManager retrieves alive nodes from > discoveryCache with specific affinity topology version and fails because of a > too short discovery history. This causes fail of exchange-worker and > therefore NoOpFailureHandler leaves node in hanging state. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-8809) Add ability to control.sh to force rebalance for specific partitions on given nodes.
[ https://issues.apache.org/jira/browse/IGNITE-8809?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16520590#comment-16520590 ] Ivan Daschinskiy commented on IGNITE-8809: -- First steps are ready. Added and tested special RebalanceRequestMessage and corresponding logic to ExchangeManager and ExchangeFuture. Trigger rebalancing by resetting updateCounters to 0 and change state of partition from owning to moving. Process special case when in message user request rebalancing for all owners. > Add ability to control.sh to force rebalance for specific partitions on given > nodes. > > > Key: IGNITE-8809 > URL: https://issues.apache.org/jira/browse/IGNITE-8809 > Project: Ignite > Issue Type: Improvement >Reporter: Alexei Scherbakov >Assignee: Ivan Daschinskiy >Priority: Major > Fix For: 2.6 > > > Sometimes it's desirable to force rebalance for specific partitions on given > nodes, for example, for test reasons or fixing synchronizations issues > without nodes downtime. > control.sh should contain new command: rebalance, which will execute the > exchange request carried by new message type, containing partitions for > rebalancing and mode: full (evict + move) or delta (historical, using > counters). > Example: > control.sh --rebalance [full|delta] nodeId:p1,p2,p3 node2:p4,p5 ... -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Comment Edited] (IGNITE-8820) Add ability to accept changing txTimeoutOnPartitionMapExchange while waiting for pending transactions.
[
https://issues.apache.org/jira/browse/IGNITE-8820?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16520224#comment-16520224
]
Ivan Daschinskiy edited comment on IGNITE-8820 at 6/22/18 11:28 AM:
[~ascherbakov]
1. Yes, I will add it to ExchangeFuture and explanation of my decision is below.
2. ExchangeFuture is waiting for partition release during init phase, so we are
hangs in exchFut.init, before exchFut.get()
{code:java}
exchFut.init(newCrd);
int dumpCnt = 0;
final long dumpTimeout = 2 *
cctx.gridConfig().getNetworkTimeout();
long nextDumpTime = 0;
while (true) {
try {
resVer = exchFut.get(dumpTimeout);
{code}
So rollback code is not neccessary at all in ExchangeManager. I'll refactor a
little bit exchangeFuture init and waitForPartitionRelease to ensure that
rollback logic executed once.
was (Author: ivandasch):
[~ascherbakov]
1. Yes, I will add it to ExchangeFuture and explanation is below.
2. ExchangeFuture are waiting for partition release during init phase, so we
are hangs in exchFut.init, before exchFut.get()
{code:java}
exchFut.init(newCrd);
int dumpCnt = 0;
final long dumpTimeout = 2 *
cctx.gridConfig().getNetworkTimeout();
long nextDumpTime = 0;
while (true) {
try {
resVer = exchFut.get(dumpTimeout);
{code}
So rollback code is not neccessary at all in ExchangeManager. I'll refactor a
little bit exchangeFuture init and waitForPartitionRelease to ensure that
rollback logic executed once.
> Add ability to accept changing txTimeoutOnPartitionMapExchange while waiting
> for pending transactions.
> --
>
> Key: IGNITE-8820
> URL: https://issues.apache.org/jira/browse/IGNITE-8820
> Project: Ignite
> Issue Type: Improvement
>Affects Versions: 2.5
>Reporter: Ivan Daschinskiy
>Assignee: Ivan Daschinskiy
>Priority: Minor
> Fix For: 2.6
>
>
> Currently, if ExchangeFuture waits whith old value of
> txTimeoutOnPartitionMapExchange, new value is not accepted until next
> exchange starts. Sometimes it's very usefull (while timeout is too long and
> must be shorter applied immediatelly)
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-8820) Add ability to accept changing txTimeoutOnPartitionMapExchange while waiting for pending transactions.
[
https://issues.apache.org/jira/browse/IGNITE-8820?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16520224#comment-16520224
]
Ivan Daschinskiy commented on IGNITE-8820:
--
[~ascherbakov]
1. Yes, I will add it to ExchangeFuture and explanation is below.
2. ExchangeFuture are waiting for partition release during init phase, so we
are hangs in exchFut.init, before exchFut.get()
{code:java}
exchFut.init(newCrd);
int dumpCnt = 0;
final long dumpTimeout = 2 *
cctx.gridConfig().getNetworkTimeout();
long nextDumpTime = 0;
while (true) {
try {
resVer = exchFut.get(dumpTimeout);
{code}
So rollback code is not neccessary at all in ExchangeManager. I'll refactor a
little bit exchangeFuture init and waitForPartitionRelease to ensure that
rollback logic executed once.
> Add ability to accept changing txTimeoutOnPartitionMapExchange while waiting
> for pending transactions.
> --
>
> Key: IGNITE-8820
> URL: https://issues.apache.org/jira/browse/IGNITE-8820
> Project: Ignite
> Issue Type: Improvement
>Affects Versions: 2.5
>Reporter: Ivan Daschinskiy
>Assignee: Ivan Daschinskiy
>Priority: Minor
> Fix For: 2.6
>
>
> Currently, if ExchangeFuture waits whith old value of
> txTimeoutOnPartitionMapExchange, new value is not accepted until next
> exchange starts. Sometimes it's very usefull (while timeout is too long and
> must be shorter applied immediatelly)
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-8820) Add ability to accept changing txTimeoutOnPartitionMapExchange while waiting for pending transactions.
[ https://issues.apache.org/jira/browse/IGNITE-8820?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16520104#comment-16520104 ] Ivan Daschinskiy commented on IGNITE-8820: -- [~ascherbakov] Alexei, I've just removed some copypaste from GridPartitionExchangeManager, kept all logic regarding transactions rollback when waiting for partition release in GridDhtPartitionsExchangeFuture. Could you please take a look again? > Add ability to accept changing txTimeoutOnPartitionMapExchange while waiting > for pending transactions. > -- > > Key: IGNITE-8820 > URL: https://issues.apache.org/jira/browse/IGNITE-8820 > Project: Ignite > Issue Type: Improvement >Affects Versions: 2.5 >Reporter: Ivan Daschinskiy >Assignee: Ivan Daschinskiy >Priority: Minor > Fix For: 2.6 > > > Currently, if ExchangeFuture waits whith old value of > txTimeoutOnPartitionMapExchange, new value is not accepted until next > exchange starts. Sometimes it's very usefull (while timeout is too long and > must be shorter applied immediatelly) -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Assigned] (IGNITE-8809) Add ability to control.sh to force rebalance for specific partitions on given nodes.
[ https://issues.apache.org/jira/browse/IGNITE-8809?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ivan Daschinskiy reassigned IGNITE-8809: Assignee: Ivan Daschinskiy > Add ability to control.sh to force rebalance for specific partitions on given > nodes. > > > Key: IGNITE-8809 > URL: https://issues.apache.org/jira/browse/IGNITE-8809 > Project: Ignite > Issue Type: Improvement >Reporter: Alexei Scherbakov >Assignee: Ivan Daschinskiy >Priority: Major > Fix For: 2.6 > > > Sometimes it's desirable to force rebalance for specific partitions on given > nodes, for example, for test reasons or fixing synchronizations issues > without nodes downtime. > control.sh should contain new command: rebalance, which will execute the > exchange request carried by new message type, containing partitions for > rebalancing and mode: full (evict + move) or delta (historical, using > counters). > Example: > control.sh --rebalance [full|delta] nodeId:p1,p2,p3 node2:p4,p5 ... -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-8820) Add ability to accept changing txTimeoutOnPartitionMapExchange while waiting for pending transactions.
Ivan Daschinskiy created IGNITE-8820: Summary: Add ability to accept changing txTimeoutOnPartitionMapExchange while waiting for pending transactions. Key: IGNITE-8820 URL: https://issues.apache.org/jira/browse/IGNITE-8820 Project: Ignite Issue Type: Improvement Affects Versions: 2.5 Reporter: Ivan Daschinskiy Assignee: Ivan Daschinskiy Fix For: 2.6 Currently, if ExchangeFuture waits whith old value of txTimeoutOnPartitionMapExchange, new value is not accepted until next exchange starts. Sometimes it's very usefull (while timeout is too long and must be shorter applied immediatelly) -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Assigned] (IGNITE-8755) NegativeArraySizeException when trying to serialize in GridClientOptimizedMarshaller humongous object
[
https://issues.apache.org/jira/browse/IGNITE-8755?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ivan Daschinskiy reassigned IGNITE-8755:
Assignee: Ivan Daschinskiy
> NegativeArraySizeException when trying to serialize in
> GridClientOptimizedMarshaller humongous object
> -
>
> Key: IGNITE-8755
> URL: https://issues.apache.org/jira/browse/IGNITE-8755
> Project: Ignite
> Issue Type: Bug
> Components: binary
>Affects Versions: 2.5
>Reporter: Ivan Daschinskiy
>Assignee: Ivan Daschinskiy
>Priority: Major
> Fix For: 2.6
>
>
> When trying to serialize humongous object in GridClientOptimizedMarshaller,
> NegativeArraySizeException thrown. See below
> {code:java}
> java.io.IOException: class org.apache.ignite.IgniteCheckedException: Failed
> to serialize object: GridClientResponse [clientId=null, reqId=0, destId=null,
> status=0, errMsg=null,
> result=org.apache.ignite.internal.processors.rest.protocols.tcp.TcpRestParserSelfTest$HugeObject@60a582c1]
> at
> org.apache.ignite.internal.client.marshaller.optimized.GridClientOptimizedMarshaller.marshal(GridClientOptimizedMarshaller.java:101)
> at
> org.apache.ignite.internal.processors.rest.protocols.tcp.TcpRestParserSelfTest.testHugeObject(TcpRestParserSelfTest.java:103)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at junit.framework.TestCase.runTest(TestCase.java:176)
> at
> org.apache.ignite.testframework.junits.GridAbstractTest.runTestInternal(GridAbstractTest.java:2086)
> at
> org.apache.ignite.testframework.junits.GridAbstractTest.access$000(GridAbstractTest.java:140)
> at
> org.apache.ignite.testframework.junits.GridAbstractTest$5.run(GridAbstractTest.java:2001)
> at java.lang.Thread.run(Thread.java:748)
> Caused by: class org.apache.ignite.IgniteCheckedException: Failed to
> serialize object: GridClientResponse [clientId=null, reqId=0, destId=null,
> status=0, errMsg=null,
> result=org.apache.ignite.internal.processors.rest.protocols.tcp.TcpRestParserSelfTest$HugeObject@60a582c1]
> at
> org.apache.ignite.internal.marshaller.optimized.OptimizedMarshaller.marshal0(OptimizedMarshaller.java:206)
> at
> org.apache.ignite.marshaller.AbstractNodeNameAwareMarshaller.marshal(AbstractNodeNameAwareMarshaller.java:58)
> at
> org.apache.ignite.internal.util.IgniteUtils.marshal(IgniteUtils.java:10059)
> at
> org.apache.ignite.internal.client.marshaller.optimized.GridClientOptimizedMarshaller.marshal(GridClientOptimizedMarshaller.java:88)
> ... 10 more
> Caused by: java.lang.NegativeArraySizeException
> at
> org.apache.ignite.internal.util.io.GridUnsafeDataOutput.requestFreeSize(GridUnsafeDataOutput.java:131)
> at
> org.apache.ignite.internal.util.io.GridUnsafeDataOutput.write(GridUnsafeDataOutput.java:166)
> at
> org.apache.ignite.internal.marshaller.optimized.OptimizedObjectOutputStream.write(OptimizedObjectOutputStream.java:142)
> at
> org.apache.ignite.internal.processors.rest.protocols.tcp.TcpRestParserSelfTest$HugeObject.writeExternal(TcpRestParserSelfTest.java:122)
> at
> org.apache.ignite.internal.marshaller.optimized.OptimizedObjectOutputStream.writeExternalizable(OptimizedObjectOutputStream.java:319)
> at
> org.apache.ignite.internal.marshaller.optimized.OptimizedClassDescriptor.write(OptimizedClassDescriptor.java:814)
> at
> org.apache.ignite.internal.marshaller.optimized.OptimizedObjectOutputStream.writeObject0(OptimizedObjectOutputStream.java:242)
> at
> org.apache.ignite.internal.marshaller.optimized.OptimizedObjectOutputStream.writeObjectOverride(OptimizedObjectOutputStream.java:159)
> at java.io.ObjectOutputStream.writeObject(ObjectOutputStream.java:344)
> at
> org.apache.ignite.internal.processors.rest.client.message.GridClientResponse.writeExternal(GridClientResponse.java:103)
> at
> org.apache.ignite.internal.marshaller.optimized.OptimizedObjectOutputStream.writeExternalizable(OptimizedObjectOutputStream.java:319)
> at
> org.apache.ignite.internal.marshaller.optimized.OptimizedClassDescriptor.write(OptimizedClassDescriptor.java:814)
> at
> org.apache.ignite.internal.marshaller.optimized.OptimizedObjectOutputStream.writeObject0(OptimizedObjectOutputStream.java:242)
> at
> org.apache.ignite.internal.marshaller.optimized.OptimizedObjectOutputStream.writeObjectOverride(OptimizedObjectOutputStream.java:159)
>
[jira] [Created] (IGNITE-8755) NegativeArraySizeException when trying to serialize in GridClientOptimizedMarshaller humongous object
Ivan Daschinskiy created IGNITE-8755:
Summary: NegativeArraySizeException when trying to serialize in
GridClientOptimizedMarshaller humongous object
Key: IGNITE-8755
URL: https://issues.apache.org/jira/browse/IGNITE-8755
Project: Ignite
Issue Type: Bug
Components: binary
Affects Versions: 2.5
Reporter: Ivan Daschinskiy
Fix For: 2.6
When trying to serialize humongous object in GridClientOptimizedMarshaller,
NegativeArraySizeException thrown. See below
{code:java}
java.io.IOException: class org.apache.ignite.IgniteCheckedException: Failed to
serialize object: GridClientResponse [clientId=null, reqId=0, destId=null,
status=0, errMsg=null,
result=org.apache.ignite.internal.processors.rest.protocols.tcp.TcpRestParserSelfTest$HugeObject@60a582c1]
at
org.apache.ignite.internal.client.marshaller.optimized.GridClientOptimizedMarshaller.marshal(GridClientOptimizedMarshaller.java:101)
at
org.apache.ignite.internal.processors.rest.protocols.tcp.TcpRestParserSelfTest.testHugeObject(TcpRestParserSelfTest.java:103)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at junit.framework.TestCase.runTest(TestCase.java:176)
at
org.apache.ignite.testframework.junits.GridAbstractTest.runTestInternal(GridAbstractTest.java:2086)
at
org.apache.ignite.testframework.junits.GridAbstractTest.access$000(GridAbstractTest.java:140)
at
org.apache.ignite.testframework.junits.GridAbstractTest$5.run(GridAbstractTest.java:2001)
at java.lang.Thread.run(Thread.java:748)
Caused by: class org.apache.ignite.IgniteCheckedException: Failed to serialize
object: GridClientResponse [clientId=null, reqId=0, destId=null, status=0,
errMsg=null,
result=org.apache.ignite.internal.processors.rest.protocols.tcp.TcpRestParserSelfTest$HugeObject@60a582c1]
at
org.apache.ignite.internal.marshaller.optimized.OptimizedMarshaller.marshal0(OptimizedMarshaller.java:206)
at
org.apache.ignite.marshaller.AbstractNodeNameAwareMarshaller.marshal(AbstractNodeNameAwareMarshaller.java:58)
at
org.apache.ignite.internal.util.IgniteUtils.marshal(IgniteUtils.java:10059)
at
org.apache.ignite.internal.client.marshaller.optimized.GridClientOptimizedMarshaller.marshal(GridClientOptimizedMarshaller.java:88)
... 10 more
Caused by: java.lang.NegativeArraySizeException
at
org.apache.ignite.internal.util.io.GridUnsafeDataOutput.requestFreeSize(GridUnsafeDataOutput.java:131)
at
org.apache.ignite.internal.util.io.GridUnsafeDataOutput.write(GridUnsafeDataOutput.java:166)
at
org.apache.ignite.internal.marshaller.optimized.OptimizedObjectOutputStream.write(OptimizedObjectOutputStream.java:142)
at
org.apache.ignite.internal.processors.rest.protocols.tcp.TcpRestParserSelfTest$HugeObject.writeExternal(TcpRestParserSelfTest.java:122)
at
org.apache.ignite.internal.marshaller.optimized.OptimizedObjectOutputStream.writeExternalizable(OptimizedObjectOutputStream.java:319)
at
org.apache.ignite.internal.marshaller.optimized.OptimizedClassDescriptor.write(OptimizedClassDescriptor.java:814)
at
org.apache.ignite.internal.marshaller.optimized.OptimizedObjectOutputStream.writeObject0(OptimizedObjectOutputStream.java:242)
at
org.apache.ignite.internal.marshaller.optimized.OptimizedObjectOutputStream.writeObjectOverride(OptimizedObjectOutputStream.java:159)
at java.io.ObjectOutputStream.writeObject(ObjectOutputStream.java:344)
at
org.apache.ignite.internal.processors.rest.client.message.GridClientResponse.writeExternal(GridClientResponse.java:103)
at
org.apache.ignite.internal.marshaller.optimized.OptimizedObjectOutputStream.writeExternalizable(OptimizedObjectOutputStream.java:319)
at
org.apache.ignite.internal.marshaller.optimized.OptimizedClassDescriptor.write(OptimizedClassDescriptor.java:814)
at
org.apache.ignite.internal.marshaller.optimized.OptimizedObjectOutputStream.writeObject0(OptimizedObjectOutputStream.java:242)
at
org.apache.ignite.internal.marshaller.optimized.OptimizedObjectOutputStream.writeObjectOverride(OptimizedObjectOutputStream.java:159)
at java.io.ObjectOutputStream.writeObject(ObjectOutputStream.java:344)
at
org.apache.ignite.internal.marshaller.optimized.OptimizedMarshaller.marshal0(OptimizedMarshaller.java:201)
{code}
The main cause of this that GridClientOptimizedMarshaller marshall object
through OptimizedMarshaller without backed OutputStream, so arithmetical
overflow occurs in
[jira] [Assigned] (IGNITE-8203) Interrupting task can cause node fail with PersistenceStorageIOException.
[ https://issues.apache.org/jira/browse/IGNITE-8203?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ivan Daschinskiy reassigned IGNITE-8203: Assignee: (was: Ivan Daschinskiy) > Interrupting task can cause node fail with PersistenceStorageIOException. > -- > > Key: IGNITE-8203 > URL: https://issues.apache.org/jira/browse/IGNITE-8203 > Project: Ignite > Issue Type: Bug > Components: persistence >Affects Versions: 2.4 >Reporter: Ivan Daschinskiy >Priority: Major > Fix For: 2.6 > > Attachments: GridFailNodesOnCanceledTaskTest.java > > > Interrupting task with simple cache operations (i.e. get, put) can cause > PersistenceStorageIOException. Main cause of this failure is lack of proper > handling InterruptedException in FilePageStore.init() etc. This cause a throw > of ClosedByInterruptException by FileChannel.write() and so on. > PersistenceStorageIOException is a critical failure and typically makes a > node to stop. As a workaround, I would suggest to enable AsyncFileIO by > default until the fix was available. > A reproducer is attached. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Comment Edited] (IGNITE-8203) Interrupting task can cause node fail with PersistenceStorageIOException.
[ https://issues.apache.org/jira/browse/IGNITE-8203?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16504488#comment-16504488 ] Ivan Daschinskiy edited comment on IGNITE-8203 at 6/7/18 10:02 AM: --- I'm a little bit stuck in fixing this issue. Currently, I fixed initialization of pagestore and my reproducer passes. But, after discussion with Alexey, I realized that this is not enough. Read and write are unfortunatelly still vulnerable to interruptions. Unfortunatelly, my reproducer doesn't touch these situations was (Author: ivandasch): I'm a little bit stuck in fixing this issue. Currently, I fixed initialization and my reproducer passes. But, after discussion with Alexey, I realized that this is not enough. Read and write are unfortunatelly still vulnerable to this issue. > Interrupting task can cause node fail with PersistenceStorageIOException. > -- > > Key: IGNITE-8203 > URL: https://issues.apache.org/jira/browse/IGNITE-8203 > Project: Ignite > Issue Type: Bug > Components: persistence >Affects Versions: 2.4 >Reporter: Ivan Daschinskiy >Assignee: Ivan Daschinskiy >Priority: Major > Fix For: 2.6 > > Attachments: GridFailNodesOnCanceledTaskTest.java > > > Interrupting task with simple cache operations (i.e. get, put) can cause > PersistenceStorageIOException. Main cause of this failure is lack of proper > handling InterruptedException in FilePageStore.init() etc. This cause a throw > of ClosedByInterruptException by FileChannel.write() and so on. > PersistenceStorageIOException is a critical failure and typically makes a > node to stop. As a workaround, I would suggest to enable AsyncFileIO by > default until the fix was available. > A reproducer is attached. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-8203) Interrupting task can cause node fail with PersistenceStorageIOException.
[ https://issues.apache.org/jira/browse/IGNITE-8203?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16504488#comment-16504488 ] Ivan Daschinskiy commented on IGNITE-8203: -- I'm a little bit stuck in fixing this issue. Currently, I fixed initialization and my reproducer passes. But, after discussion with Alexey, I realized that this is not enough. Read and write are unfortunatelly still vulnerable to this issue. > Interrupting task can cause node fail with PersistenceStorageIOException. > -- > > Key: IGNITE-8203 > URL: https://issues.apache.org/jira/browse/IGNITE-8203 > Project: Ignite > Issue Type: Bug > Components: persistence >Affects Versions: 2.4 >Reporter: Ivan Daschinskiy >Assignee: Ivan Daschinskiy >Priority: Major > Fix For: 2.6 > > Attachments: GridFailNodesOnCanceledTaskTest.java > > > Interrupting task with simple cache operations (i.e. get, put) can cause > PersistenceStorageIOException. Main cause of this failure is lack of proper > handling InterruptedException in FilePageStore.init() etc. This cause a throw > of ClosedByInterruptException by FileChannel.write() and so on. > PersistenceStorageIOException is a critical failure and typically makes a > node to stop. As a workaround, I would suggest to enable AsyncFileIO by > default until the fix was available. > A reproducer is attached. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-8624) Add test coverage for NPE in TTL Manager [IGNITE-7972]
[ https://issues.apache.org/jira/browse/IGNITE-8624?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16492815#comment-16492815 ] Ivan Daschinskiy commented on IGNITE-8624: -- [~dpavlov] please, review my issue. After TC run my test successfully passes. > Add test coverage for NPE in TTL Manager [IGNITE-7972] > -- > > Key: IGNITE-8624 > URL: https://issues.apache.org/jira/browse/IGNITE-8624 > Project: Ignite > Issue Type: Test >Reporter: Ivan Daschinskiy >Assignee: Ivan Daschinskiy >Priority: Minor > Fix For: 2.6 > > > Add test coverage (reproducer) to the [IGNITE-7972] case. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-8624) Add test coverage for NPE in TTL Manager [IGNITE-7972]
[ https://issues.apache.org/jira/browse/IGNITE-8624?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ivan Daschinskiy updated IGNITE-8624: - Fix Version/s: 2.6 > Add test coverage for NPE in TTL Manager [IGNITE-7972] > -- > > Key: IGNITE-8624 > URL: https://issues.apache.org/jira/browse/IGNITE-8624 > Project: Ignite > Issue Type: Test >Reporter: Ivan Daschinskiy >Assignee: Ivan Daschinskiy >Priority: Minor > Fix For: 2.6 > > > Add test coverage (reproducer) to the [IGNITE-7972] case. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-8624) Add test coverage for NPE in TTL Manager [IGNITE-7972]
[ https://issues.apache.org/jira/browse/IGNITE-8624?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ivan Daschinskiy updated IGNITE-8624: - Affects Version/s: (was: 2.4) > Add test coverage for NPE in TTL Manager [IGNITE-7972] > -- > > Key: IGNITE-8624 > URL: https://issues.apache.org/jira/browse/IGNITE-8624 > Project: Ignite > Issue Type: Test >Reporter: Ivan Daschinskiy >Assignee: Ivan Daschinskiy >Priority: Minor > Fix For: 2.6 > > > Add test coverage (reproducer) to the [IGNITE-7972] case. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-8624) Add test coverage for NPE in TTL Manager [IGNITE-7972]
[ https://issues.apache.org/jira/browse/IGNITE-8624?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ivan Daschinskiy updated IGNITE-8624: - Affects Version/s: 2.4 > Add test coverage for NPE in TTL Manager [IGNITE-7972] > -- > > Key: IGNITE-8624 > URL: https://issues.apache.org/jira/browse/IGNITE-8624 > Project: Ignite > Issue Type: Test >Reporter: Ivan Daschinskiy >Assignee: Ivan Daschinskiy >Priority: Minor > Fix For: 2.6 > > > Add test coverage (reproducer) to the [IGNITE-7972] case. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-8624) Add test coverage for NPE in TTL Manager [IGNITE-7972]
Ivan Daschinskiy created IGNITE-8624: Summary: Add test coverage for NPE in TTL Manager [IGNITE-7972] Key: IGNITE-8624 URL: https://issues.apache.org/jira/browse/IGNITE-8624 Project: Ignite Issue Type: Test Reporter: Ivan Daschinskiy Assignee: Ivan Daschinskiy Add test coverage (reproducer) to the [IGNITE-7972] case. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Comment Edited] (IGNITE-8612) NPE in GridCacheTtlManager#expire on commit() or close() on client
[
https://issues.apache.org/jira/browse/IGNITE-8612?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16491007#comment-16491007
]
Ivan Daschinskiy edited comment on IGNITE-8612 at 5/25/18 5:08 PM:
---
I've reproduced this issue on 2.4 with attached test (see attachments) and
after your fix, [~amashenkov], reproducer passed. On master it also passes.
I suppose this is a duplicate of -IGNITE-7972-
was (Author: ivandasch):
I've reproduced this issue on 2.4 with attached test (see attachments) and
after your fix, [~amashenkov], reproducer passed. On master it also passed.
I suppose this is a duplicate of -IGNITE-7972-
> NPE in GridCacheTtlManager#expire on commit() or close() on client
> --
>
> Key: IGNITE-8612
> URL: https://issues.apache.org/jira/browse/IGNITE-8612
> Project: Ignite
> Issue Type: Bug
>Affects Versions: 2.4
>Reporter: Andrew Medvedev
>Priority: Major
> Attachments: TxOnMultipleCacheStartTest.java
>
>
> We have got NPE in
> org.apache.ignite.internal.processors.cache.GridCacheTtlManager#expire(int)
> several times during 4 minutes period from tx.close() and tx.commit() here
> [https://github.com/apache/ignite/blob/40845c67750c300b5568d157ab0ffeaf320802a8/modules/core/src/main/java/org/apache/ignite/internal/processors/cache/GridCacheTtlManager.java#L203]
>
> {{Caused by: java.lang.NullPointerException}}
> {{at
> org.apache.ignite.internal.processors.cache.GridCacheTtlManager.expire(GridCacheTtlManager.java:197)}}
> {{at
> org.apache.ignite.internal.processors.cache.GridCacheUtils.unwindEvicts(GridCacheUtils.java:834)}}
> {{at
> org.apache.ignite.internal.processors.cache.GridCacheUtils.unwindEvicts(GridCacheUtils.java:844)}}
> {{at
> org.apache.ignite.internal.processors.cache.transactions.TransactionProxyImpl.leave(TransactionProxyImpl.java:136)}}
> {{at
> org.apache.ignite.internal.processors.cache.transactions.TransactionProxyImpl.close(TransactionProxyImpl.java:326)}}
> This could have been IgniteCacheOffheapManager == null, cctx.offheap()
> returning null, but I could not reproduce it. To debug this further, a PR
> with assert added will be submitted
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Comment Edited] (IGNITE-8612) NPE in GridCacheTtlManager#expire on commit() or close() on client
[
https://issues.apache.org/jira/browse/IGNITE-8612?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16491007#comment-16491007
]
Ivan Daschinskiy edited comment on IGNITE-8612 at 5/25/18 5:07 PM:
---
I've reproduced this issue on 2.4 with attached test (see attachments) and
after your fix, [~amashenkov], reproducer passed. On master it also passed.
I suppose this is a duplicate of -IGNITE-7972-
was (Author: ivandasch):
I've reproduced this issue with attached test (see attachments) and after your
fix, [~amashenkov], reproducer passed.
I suppose this is a duplicate of -IGNITE-7972-
> NPE in GridCacheTtlManager#expire on commit() or close() on client
> --
>
> Key: IGNITE-8612
> URL: https://issues.apache.org/jira/browse/IGNITE-8612
> Project: Ignite
> Issue Type: Bug
>Affects Versions: 2.4
>Reporter: Andrew Medvedev
>Priority: Major
> Attachments: TxOnMultipleCacheStartTest.java
>
>
> We have got NPE in
> org.apache.ignite.internal.processors.cache.GridCacheTtlManager#expire(int)
> several times during 4 minutes period from tx.close() and tx.commit() here
> [https://github.com/apache/ignite/blob/40845c67750c300b5568d157ab0ffeaf320802a8/modules/core/src/main/java/org/apache/ignite/internal/processors/cache/GridCacheTtlManager.java#L203]
>
> {{Caused by: java.lang.NullPointerException}}
> {{at
> org.apache.ignite.internal.processors.cache.GridCacheTtlManager.expire(GridCacheTtlManager.java:197)}}
> {{at
> org.apache.ignite.internal.processors.cache.GridCacheUtils.unwindEvicts(GridCacheUtils.java:834)}}
> {{at
> org.apache.ignite.internal.processors.cache.GridCacheUtils.unwindEvicts(GridCacheUtils.java:844)}}
> {{at
> org.apache.ignite.internal.processors.cache.transactions.TransactionProxyImpl.leave(TransactionProxyImpl.java:136)}}
> {{at
> org.apache.ignite.internal.processors.cache.transactions.TransactionProxyImpl.close(TransactionProxyImpl.java:326)}}
> This could have been IgniteCacheOffheapManager == null, cctx.offheap()
> returning null, but I could not reproduce it. To debug this further, a PR
> with assert added will be submitted
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Resolved] (IGNITE-8612) NPE in GridCacheTtlManager#expire on commit() or close() on client
[
https://issues.apache.org/jira/browse/IGNITE-8612?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ivan Daschinskiy resolved IGNITE-8612.
--
Resolution: Duplicate
> NPE in GridCacheTtlManager#expire on commit() or close() on client
> --
>
> Key: IGNITE-8612
> URL: https://issues.apache.org/jira/browse/IGNITE-8612
> Project: Ignite
> Issue Type: Bug
>Affects Versions: 2.4
>Reporter: Andrew Medvedev
>Priority: Major
> Attachments: TxOnMultipleCacheStartTest.java
>
>
> We have got NPE in
> org.apache.ignite.internal.processors.cache.GridCacheTtlManager#expire(int)
> several times during 4 minutes period from tx.close() and tx.commit() here
> [https://github.com/apache/ignite/blob/40845c67750c300b5568d157ab0ffeaf320802a8/modules/core/src/main/java/org/apache/ignite/internal/processors/cache/GridCacheTtlManager.java#L203]
>
> {{Caused by: java.lang.NullPointerException}}
> {{at
> org.apache.ignite.internal.processors.cache.GridCacheTtlManager.expire(GridCacheTtlManager.java:197)}}
> {{at
> org.apache.ignite.internal.processors.cache.GridCacheUtils.unwindEvicts(GridCacheUtils.java:834)}}
> {{at
> org.apache.ignite.internal.processors.cache.GridCacheUtils.unwindEvicts(GridCacheUtils.java:844)}}
> {{at
> org.apache.ignite.internal.processors.cache.transactions.TransactionProxyImpl.leave(TransactionProxyImpl.java:136)}}
> {{at
> org.apache.ignite.internal.processors.cache.transactions.TransactionProxyImpl.close(TransactionProxyImpl.java:326)}}
> This could have been IgniteCacheOffheapManager == null, cctx.offheap()
> returning null, but I could not reproduce it. To debug this further, a PR
> with assert added will be submitted
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-8612) NPE in GridCacheTtlManager#expire on commit() or close() on client
[
https://issues.apache.org/jira/browse/IGNITE-8612?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16491007#comment-16491007
]
Ivan Daschinskiy commented on IGNITE-8612:
--
I've reproduced this issue with attached test (see attachments) and after your
fix, [~amashenkov], reproducer passed.
I suppose this is a duplicate of -IGNITE-7972-
> NPE in GridCacheTtlManager#expire on commit() or close() on client
> --
>
> Key: IGNITE-8612
> URL: https://issues.apache.org/jira/browse/IGNITE-8612
> Project: Ignite
> Issue Type: Bug
>Affects Versions: 2.4
>Reporter: Andrew Medvedev
>Priority: Major
> Attachments: TxOnMultipleCacheStartTest.java
>
>
> We have got NPE in
> org.apache.ignite.internal.processors.cache.GridCacheTtlManager#expire(int)
> several times during 4 minutes period from tx.close() and tx.commit() here
> [https://github.com/apache/ignite/blob/40845c67750c300b5568d157ab0ffeaf320802a8/modules/core/src/main/java/org/apache/ignite/internal/processors/cache/GridCacheTtlManager.java#L203]
>
> {{Caused by: java.lang.NullPointerException}}
> {{at
> org.apache.ignite.internal.processors.cache.GridCacheTtlManager.expire(GridCacheTtlManager.java:197)}}
> {{at
> org.apache.ignite.internal.processors.cache.GridCacheUtils.unwindEvicts(GridCacheUtils.java:834)}}
> {{at
> org.apache.ignite.internal.processors.cache.GridCacheUtils.unwindEvicts(GridCacheUtils.java:844)}}
> {{at
> org.apache.ignite.internal.processors.cache.transactions.TransactionProxyImpl.leave(TransactionProxyImpl.java:136)}}
> {{at
> org.apache.ignite.internal.processors.cache.transactions.TransactionProxyImpl.close(TransactionProxyImpl.java:326)}}
> This could have been IgniteCacheOffheapManager == null, cctx.offheap()
> returning null, but I could not reproduce it. To debug this further, a PR
> with assert added will be submitted
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (IGNITE-8612) NPE in GridCacheTtlManager#expire on commit() or close() on client
[
https://issues.apache.org/jira/browse/IGNITE-8612?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ivan Daschinskiy updated IGNITE-8612:
-
Attachment: TxOnMultipleCacheStartTest.java
> NPE in GridCacheTtlManager#expire on commit() or close() on client
> --
>
> Key: IGNITE-8612
> URL: https://issues.apache.org/jira/browse/IGNITE-8612
> Project: Ignite
> Issue Type: Bug
>Affects Versions: 2.4
>Reporter: Andrew Medvedev
>Priority: Major
> Attachments: TxOnMultipleCacheStartTest.java
>
>
> We have got NPE in
> org.apache.ignite.internal.processors.cache.GridCacheTtlManager#expire(int)
> several times during 4 minutes period from tx.close() and tx.commit() here
> [https://github.com/apache/ignite/blob/40845c67750c300b5568d157ab0ffeaf320802a8/modules/core/src/main/java/org/apache/ignite/internal/processors/cache/GridCacheTtlManager.java#L203]
>
> {{Caused by: java.lang.NullPointerException}}
> {{at
> org.apache.ignite.internal.processors.cache.GridCacheTtlManager.expire(GridCacheTtlManager.java:197)}}
> {{at
> org.apache.ignite.internal.processors.cache.GridCacheUtils.unwindEvicts(GridCacheUtils.java:834)}}
> {{at
> org.apache.ignite.internal.processors.cache.GridCacheUtils.unwindEvicts(GridCacheUtils.java:844)}}
> {{at
> org.apache.ignite.internal.processors.cache.transactions.TransactionProxyImpl.leave(TransactionProxyImpl.java:136)}}
> {{at
> org.apache.ignite.internal.processors.cache.transactions.TransactionProxyImpl.close(TransactionProxyImpl.java:326)}}
> This could have been IgniteCacheOffheapManager == null, cctx.offheap()
> returning null, but I could not reproduce it. To debug this further, a PR
> with assert added will be submitted
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-8070) .NET: FailureHandler should be added to Ignite configuration
[
https://issues.apache.org/jira/browse/IGNITE-8070?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16475309#comment-16475309
]
Ivan Daschinskiy commented on IGNITE-8070:
--
[~ptupitsyn] I suppose I've corrected all issues.Could you please review again?
TC build is attached.
> .NET: FailureHandler should be added to Ignite configuration
>
>
> Key: IGNITE-8070
> URL: https://issues.apache.org/jira/browse/IGNITE-8070
> Project: Ignite
> Issue Type: Improvement
> Components: platforms
>Reporter: Andrey Gura
>Assignee: Ivan Daschinskiy
>Priority: Major
> Labels: .NET, iep-14
>
> {{IgniteConfiguration}} class was extended by new methods:
> {{setFailureHandler}} and {{getFailureHandler}}. Corresponding changes should
> be done in ignite .Net
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Comment Edited] (IGNITE-8070) .NET: FailureHandler should be added to Ignite configuration
[
https://issues.apache.org/jira/browse/IGNITE-8070?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16473858#comment-16473858
]
Ivan Daschinskiy edited comment on IGNITE-8070 at 5/14/18 7:45 AM:
---
[~ptupitsyn] thank you for your review.
The most of your remarks are clear for me, but I have one question about one
thing. Currently I don't know
the best variant for this. Could you please add your opinion in upsource review?
was (Author: ivandasch):
[~ptupitsyn] thank you for you review.
The most of your remarks are clear for me, but I have one question about one
thing. Currently I don't know
the best variant for this. Could you please add your opinion in upsource review?
> .NET: FailureHandler should be added to Ignite configuration
>
>
> Key: IGNITE-8070
> URL: https://issues.apache.org/jira/browse/IGNITE-8070
> Project: Ignite
> Issue Type: Improvement
> Components: platforms
>Reporter: Andrey Gura
>Assignee: Ivan Daschinskiy
>Priority: Major
> Labels: .NET, iep-14
>
> {{IgniteConfiguration}} class was extended by new methods:
> {{setFailureHandler}} and {{getFailureHandler}}. Corresponding changes should
> be done in ignite .Net
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-8070) .NET: FailureHandler should be added to Ignite configuration
[
https://issues.apache.org/jira/browse/IGNITE-8070?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16473858#comment-16473858
]
Ivan Daschinskiy commented on IGNITE-8070:
--
[~ptupitsyn] thank you for you review.
The most of your remarks are clear for me, but I have one question about one
thing. Currently I don't know
the best variant for this. Could you please add your opinion in upsource review?
> .NET: FailureHandler should be added to Ignite configuration
>
>
> Key: IGNITE-8070
> URL: https://issues.apache.org/jira/browse/IGNITE-8070
> Project: Ignite
> Issue Type: Improvement
> Components: platforms
>Reporter: Andrey Gura
>Assignee: Ivan Daschinskiy
>Priority: Major
> Labels: .NET, iep-14
>
> {{IgniteConfiguration}} class was extended by new methods:
> {{setFailureHandler}} and {{getFailureHandler}}. Corresponding changes should
> be done in ignite .Net
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Comment Edited] (IGNITE-8070) .NET: FailureHandler should be added to Ignite configuration
[
https://issues.apache.org/jira/browse/IGNITE-8070?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16473519#comment-16473519
]
Ivan Daschinskiy edited comment on IGNITE-8070 at 5/13/18 4:41 PM:
---
[~ptupitsyn] Could you please review my PR.
TC run seems OK to me, 2 tests in .NET suite have failed, one is flaky, second
has failed by accident. I rerun it locally many times in my branch and always
it finishes ok.
was (Author: ivandasch):
[~ptupitsyn] Could you please review my PR.
TC run seems OK to me, 2 tests in .NET suite fails, one is flaky, second failed
by accident. I rerun it locally many times in my branch and always it finishes
ok.
> .NET: FailureHandler should be added to Ignite configuration
>
>
> Key: IGNITE-8070
> URL: https://issues.apache.org/jira/browse/IGNITE-8070
> Project: Ignite
> Issue Type: Improvement
> Components: platforms
>Reporter: Andrey Gura
>Assignee: Ivan Daschinskiy
>Priority: Major
> Labels: .NET, iep-14
>
> {{IgniteConfiguration}} class was extended by new methods:
> {{setFailureHandler}} and {{getFailureHandler}}. Corresponding changes should
> be done in ignite .Net
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-8070) .NET: FailureHandler should be added to Ignite configuration
[
https://issues.apache.org/jira/browse/IGNITE-8070?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16473519#comment-16473519
]
Ivan Daschinskiy commented on IGNITE-8070:
--
[~ptupitsyn] Could you please review my PR.
TC run seems OK to me, 2 tests in .NET suite fails, one is flaky, second failed
by accident. I rerun it locally many times in my branch and always it finishes
ok.
> .NET: FailureHandler should be added to Ignite configuration
>
>
> Key: IGNITE-8070
> URL: https://issues.apache.org/jira/browse/IGNITE-8070
> Project: Ignite
> Issue Type: Improvement
> Components: platforms
>Reporter: Andrey Gura
>Assignee: Ivan Daschinskiy
>Priority: Major
> Labels: .NET, iep-14
>
> {{IgniteConfiguration}} class was extended by new methods:
> {{setFailureHandler}} and {{getFailureHandler}}. Corresponding changes should
> be done in ignite .Net
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-7896) Files of evicted partitions are not removed from disk storage
[ https://issues.apache.org/jira/browse/IGNITE-7896?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16470624#comment-16470624 ] Ivan Daschinskiy commented on IGNITE-7896: -- [New TC run|https://ci.ignite.apache.org/viewLog.html?buildId=1280055=IgniteTests24Java8_RunAll=buildResultsDiv] > Files of evicted partitions are not removed from disk storage > - > > Key: IGNITE-7896 > URL: https://issues.apache.org/jira/browse/IGNITE-7896 > Project: Ignite > Issue Type: Bug >Reporter: Vladislav Pyatkov >Assignee: Ivan Daschinskiy >Priority: Major > Fix For: 2.6 > > Attachments: IgnitePdsRebalanceCompletionAndPartitionFilesTest.java > > > Look at test reproduction: > [^IgnitePdsRebalanceCompletionAndPartitionFilesTest.java] -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-7896) Files of evicted partitions are not removed from disk storage
[ https://issues.apache.org/jira/browse/IGNITE-7896?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16467341#comment-16467341 ] Ivan Daschinskiy commented on IGNITE-7896: -- Please, review my PR > Files of evicted partitions are not removed from disk storage > - > > Key: IGNITE-7896 > URL: https://issues.apache.org/jira/browse/IGNITE-7896 > Project: Ignite > Issue Type: Bug >Reporter: Vladislav Pyatkov >Assignee: Ivan Daschinskiy >Priority: Major > Attachments: IgnitePdsRebalanceCompletionAndPartitionFilesTest.java > > > Look at test reproduction: > [^IgnitePdsRebalanceCompletionAndPartitionFilesTest.java] -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-8437) Control utility fails to connect to cluster if zookeeper discovery used
[
https://issues.apache.org/jira/browse/IGNITE-8437?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16466105#comment-16466105
]
Ivan Daschinskiy commented on IGNITE-8437:
--
[~agoncharuk] As we can see from sources, the cause of NPE is equality to null
of MarshallerMappingTransport instance (this.transport to be precise).
Why at the moment onMarshallerProcessorStarted wasn't called – it's a
question. But I suppose this is not related to the issue
> Control utility fails to connect to cluster if zookeeper discovery used
> ---
>
> Key: IGNITE-8437
> URL: https://issues.apache.org/jira/browse/IGNITE-8437
> Project: Ignite
> Issue Type: Improvement
> Components: zookeeper
>Affects Versions: 2.5
>Reporter: Dmitry Sherstobitov
>Assignee: Alexei Scherbakov
>Priority: Blocker
>
> Start cluster with zookeeper discovery and try to run control.sh --tx utility
>
> {code:java}
> 2018-05-03 16:56:36.225
> [ERROR][mgmt-#115268%DPL_GRID%DplGridNodeName%][o.a.i.i.p.r.p.t.GridTcpRestProtocol]
> Failed to process client request [ses=GridSelectorNioSessionImpl
> [worker=ByteBufferNioClientWorker [readBuf=java.nio.HeapByteBuffer[pos=395
> lim=395 cap=8192], super=AbstractNioClientWorker [idx=0, bytesRcvd=0,
> bytesSent=0, bytesRcvd0=0, bytesSent0=0, select=true, super=GridWorker
> [name=grid-nio-worker-tcp-rest-0,
> igniteInstanceName=DPL_GRID%DplGridNodeName, finished=false,
> hashCode=1766410348, interrupted=false,
> runner=grid-nio-worker-tcp-rest-0-#48%DPL_GRID%DplGridNodeName%]]],
> writeBuf=null, readBuf=null, inRecovery=null, outRecovery=null,
> super=GridNioSessionImpl [locAddr=/10.116.158.48:11211,
> rmtAddr=/10.78.10.31:55847, createTime=1525355795984,
> closeTime=1525355796217, bytesSent=521553, bytesRcvd=461, bytesSent0=521553,
> bytesRcvd0=461, sndSchedTime=1525355796217, lastSndTime=1525355796075,
> lastRcvTime=1525355796175, readsPaused=false,
> filterChain=FilterChain[filters=[GridNioCodecFilter [parser=GridTcpRestParser
> [marsh=JdkMarshaller [clsFilter=o.a.i.i.IgniteKernal$5@3e3d1d0d],
> routerClient=false], directMode=false]], accepted=true]],
> msg=GridClientTaskRequest [taskName=o.a.i.i.v.tx.VisorTxTask,
> arg=VisorTaskArgument [debug=false]]]
> org.apache.ignite.internal.util.nio.GridNioException: class
> org.apache.ignite.IgniteCheckedException: Failed to serialize object:
> GridClientResponse [clientId=587ea745-dd1e-4631-aa85-feb5d49acc36, reqId=2,
> destId=null, status=0, errMsg=null, result=GridClientTaskResultBean
> [res={ZookeeperClusterNode [id=c4cc818d-b29f-427b-86b5-9a625287feb6,
> addrs=[10.116.159.100], order=30, loc=false, client=true]=VisorTxTaskResult
> []}, error=null, finished=true, id=~a7245b33-a37a-4084-a954-460c31834442]]
> at
> org.apache.ignite.internal.util.nio.GridNioCodecFilter.onSessionWrite(GridNioCodecFilter.java:100)
> at
> org.apache.ignite.internal.util.nio.GridNioFilterAdapter.proceedSessionWrite(GridNioFilterAdapter.java:121)
> at
> org.apache.ignite.internal.util.nio.GridNioFilterChain$TailFilter.onSessionWrite(GridNioFilterChain.java:269)
> at
> org.apache.ignite.internal.util.nio.GridNioFilterChain.onSessionWrite(GridNioFilterChain.java:192)
> at
> org.apache.ignite.internal.util.nio.GridNioSessionImpl.send(GridNioSessionImpl.java:110)
> at
> org.apache.ignite.internal.processors.rest.protocols.tcp.GridTcpRestNioListener$1.apply(GridTcpRestNioListener.java:261)
> at
> org.apache.ignite.internal.processors.rest.protocols.tcp.GridTcpRestNioListener$1.apply(GridTcpRestNioListener.java:232)
> at
> org.apache.ignite.internal.util.future.GridFutureAdapter.notifyListener(GridFutureAdapter.java:383)
> at
> org.apache.ignite.internal.util.future.GridFutureAdapter.unblock(GridFutureAdapter.java:347)
> at
> org.apache.ignite.internal.util.future.GridFutureAdapter.unblockAll(GridFutureAdapter.java:335)
> at
> org.apache.ignite.internal.util.future.GridFutureAdapter.onDone(GridFutureAdapter.java:495)
> at
> org.apache.ignite.internal.util.future.GridFutureAdapter.onDone(GridFutureAdapter.java:474)
> at
> org.apache.ignite.internal.util.future.GridFutureAdapter.onDone(GridFutureAdapter.java:451)
> at
> org.apache.ignite.internal.processors.rest.GridRestProcessor$2$1.apply(GridRestProcessor.java:165)
> at
> org.apache.ignite.internal.processors.rest.GridRestProcessor$2$1.apply(GridRestProcessor.java:162)
> at
> org.apache.ignite.internal.util.future.GridFutureAdapter.notifyListener(GridFutureAdapter.java:383)
> at
> org.apache.ignite.internal.util.future.GridFutureAdapter.unblock(GridFutureAdapter.java:347)
> at
> org.apache.ignite.internal.util.future.GridFutureAdapter.unblockAll(GridFutureAdapter.java:335)
> at
>
[jira] [Commented] (IGNITE-7912) control.sh script should show used WAL-segments
[ https://issues.apache.org/jira/browse/IGNITE-7912?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16465939#comment-16465939 ] Ivan Daschinskiy commented on IGNITE-7912: -- Merged latest changes and added newest TC build. Tests seems to be ok. > control.sh script should show used WAL-segments > --- > > Key: IGNITE-7912 > URL: https://issues.apache.org/jira/browse/IGNITE-7912 > Project: Ignite > Issue Type: Improvement >Reporter: Sergey Filatov >Assignee: Ivan Daschinskiy >Priority: Minor > > We have to erase wal archive because wal archive can grow large and we must > have safe way to remove unused segments to free disk space. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Comment Edited] (IGNITE-8437) Control utility fails to connect to cluster if zookeeper discovery used
[
https://issues.apache.org/jira/browse/IGNITE-8437?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16465838#comment-16465838
]
Ivan Daschinskiy edited comment on IGNITE-8437 at 5/7/18 12:19 PM:
---
[~ascherbakov] I suppose, that it's necessary also add this to pom.xml in
zookeeper module:
{code:xml}
org.codehaus.mojo
exec-maven-plugin
1.3.2
org.apache.ignite
ignite-tools
${project.version}
process-classes
java
true
org.apache.ignite.tools.classgen.ClassesGenerator
${project.basedir}/target/classes
org.apache.ignite.spi.discovery.zk.internal
{code}
was (Author: ivandasch):
[~ascherbakov] I suppose, that it's necessary also add this to pom.xml in
zookeeper module:
{code:xml}
org.codehaus.mojo
exec-maven-plugin
1.3.2
org.apache.ignite
ignite-tools
${project.version}
process-classes
java
true
org.apache.ignite.tools.classgen.ClassesGenerator
${project.basedir}/target/classes
org.apache.ignite.hadoop:org.apache.ignite.internal.processors.hadoop
{code}
> Control utility fails to connect to cluster if zookeeper discovery used
> ---
>
> Key: IGNITE-8437
> URL: https://issues.apache.org/jira/browse/IGNITE-8437
> Project: Ignite
> Issue Type: Improvement
> Components: zookeeper
>Affects Versions: 2.5
>Reporter: Dmitry Sherstobitov
>Assignee: Alexei Scherbakov
>Priority: Blocker
>
> Start cluster with zookeeper discovery and try to run control.sh --tx utility
>
> {code:java}
> 2018-05-03 16:56:36.225
> [ERROR][mgmt-#115268%DPL_GRID%DplGridNodeName%][o.a.i.i.p.r.p.t.GridTcpRestProtocol]
> Failed to process client request [ses=GridSelectorNioSessionImpl
> [worker=ByteBufferNioClientWorker [readBuf=java.nio.HeapByteBuffer[pos=395
> lim=395 cap=8192], super=AbstractNioClientWorker [idx=0, bytesRcvd=0,
> bytesSent=0, bytesRcvd0=0, bytesSent0=0, select=true, super=GridWorker
> [name=grid-nio-worker-tcp-rest-0,
> igniteInstanceName=DPL_GRID%DplGridNodeName, finished=false,
> hashCode=1766410348, interrupted=false,
> runner=grid-nio-worker-tcp-rest-0-#48%DPL_GRID%DplGridNodeName%]]],
> writeBuf=null, readBuf=null, inRecovery=null, outRecovery=null,
> super=GridNioSessionImpl [locAddr=/10.116.158.48:11211,
> rmtAddr=/10.78.10.31:55847, createTime=1525355795984,
> closeTime=1525355796217, bytesSent=521553, bytesRcvd=461, bytesSent0=521553,
> bytesRcvd0=461, sndSchedTime=1525355796217, lastSndTime=1525355796075,
> lastRcvTime=1525355796175, readsPaused=false,
> filterChain=FilterChain[filters=[GridNioCodecFilter [parser=GridTcpRestParser
> [marsh=JdkMarshaller [clsFilter=o.a.i.i.IgniteKernal$5@3e3d1d0d],
> routerClient=false], directMode=false]], accepted=true]],
> msg=GridClientTaskRequest [taskName=o.a.i.i.v.tx.VisorTxTask,
> arg=VisorTaskArgument [debug=false]]]
> org.apache.ignite.internal.util.nio.GridNioException: class
> org.apache.ignite.IgniteCheckedException: Failed to serialize object:
> GridClientResponse [clientId=587ea745-dd1e-4631-aa85-feb5d49acc36, reqId=2,
> destId=null, status=0, errMsg=null, result=GridClientTaskResultBean
> [res={ZookeeperClusterNode [id=c4cc818d-b29f-427b-86b5-9a625287feb6,
> addrs=[10.116.159.100], order=30, loc=false, client=true]=VisorTxTaskResult
> []}, error=null, finished=true, id=~a7245b33-a37a-4084-a954-460c31834442]]
> at
>
[jira] [Commented] (IGNITE-8437) Control utility fails to connect to cluster if zookeeper discovery used
[
https://issues.apache.org/jira/browse/IGNITE-8437?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16465838#comment-16465838
]
Ivan Daschinskiy commented on IGNITE-8437:
--
[~ascherbakov] I suppose, that it's necessary also add this to pom.xml in
zookeeper module:
{code:xml}
org.codehaus.mojo
exec-maven-plugin
1.3.2
org.apache.ignite
ignite-tools
${project.version}
process-classes
java
true
org.apache.ignite.tools.classgen.ClassesGenerator
${project.basedir}/target/classes
org.apache.ignite.hadoop:org.apache.ignite.internal.processors.hadoop
{code}
> Control utility fails to connect to cluster if zookeeper discovery used
> ---
>
> Key: IGNITE-8437
> URL: https://issues.apache.org/jira/browse/IGNITE-8437
> Project: Ignite
> Issue Type: Improvement
> Components: zookeeper
>Affects Versions: 2.5
>Reporter: Dmitry Sherstobitov
>Assignee: Alexei Scherbakov
>Priority: Blocker
>
> Start cluster with zookeeper discovery and try to run control.sh --tx utility
>
> {code:java}
> 2018-05-03 16:56:36.225
> [ERROR][mgmt-#115268%DPL_GRID%DplGridNodeName%][o.a.i.i.p.r.p.t.GridTcpRestProtocol]
> Failed to process client request [ses=GridSelectorNioSessionImpl
> [worker=ByteBufferNioClientWorker [readBuf=java.nio.HeapByteBuffer[pos=395
> lim=395 cap=8192], super=AbstractNioClientWorker [idx=0, bytesRcvd=0,
> bytesSent=0, bytesRcvd0=0, bytesSent0=0, select=true, super=GridWorker
> [name=grid-nio-worker-tcp-rest-0,
> igniteInstanceName=DPL_GRID%DplGridNodeName, finished=false,
> hashCode=1766410348, interrupted=false,
> runner=grid-nio-worker-tcp-rest-0-#48%DPL_GRID%DplGridNodeName%]]],
> writeBuf=null, readBuf=null, inRecovery=null, outRecovery=null,
> super=GridNioSessionImpl [locAddr=/10.116.158.48:11211,
> rmtAddr=/10.78.10.31:55847, createTime=1525355795984,
> closeTime=1525355796217, bytesSent=521553, bytesRcvd=461, bytesSent0=521553,
> bytesRcvd0=461, sndSchedTime=1525355796217, lastSndTime=1525355796075,
> lastRcvTime=1525355796175, readsPaused=false,
> filterChain=FilterChain[filters=[GridNioCodecFilter [parser=GridTcpRestParser
> [marsh=JdkMarshaller [clsFilter=o.a.i.i.IgniteKernal$5@3e3d1d0d],
> routerClient=false], directMode=false]], accepted=true]],
> msg=GridClientTaskRequest [taskName=o.a.i.i.v.tx.VisorTxTask,
> arg=VisorTaskArgument [debug=false]]]
> org.apache.ignite.internal.util.nio.GridNioException: class
> org.apache.ignite.IgniteCheckedException: Failed to serialize object:
> GridClientResponse [clientId=587ea745-dd1e-4631-aa85-feb5d49acc36, reqId=2,
> destId=null, status=0, errMsg=null, result=GridClientTaskResultBean
> [res={ZookeeperClusterNode [id=c4cc818d-b29f-427b-86b5-9a625287feb6,
> addrs=[10.116.159.100], order=30, loc=false, client=true]=VisorTxTaskResult
> []}, error=null, finished=true, id=~a7245b33-a37a-4084-a954-460c31834442]]
> at
> org.apache.ignite.internal.util.nio.GridNioCodecFilter.onSessionWrite(GridNioCodecFilter.java:100)
> at
> org.apache.ignite.internal.util.nio.GridNioFilterAdapter.proceedSessionWrite(GridNioFilterAdapter.java:121)
> at
> org.apache.ignite.internal.util.nio.GridNioFilterChain$TailFilter.onSessionWrite(GridNioFilterChain.java:269)
> at
> org.apache.ignite.internal.util.nio.GridNioFilterChain.onSessionWrite(GridNioFilterChain.java:192)
> at
> org.apache.ignite.internal.util.nio.GridNioSessionImpl.send(GridNioSessionImpl.java:110)
> at
> org.apache.ignite.internal.processors.rest.protocols.tcp.GridTcpRestNioListener$1.apply(GridTcpRestNioListener.java:261)
> at
> org.apache.ignite.internal.processors.rest.protocols.tcp.GridTcpRestNioListener$1.apply(GridTcpRestNioListener.java:232)
> at
> org.apache.ignite.internal.util.future.GridFutureAdapter.notifyListener(GridFutureAdapter.java:383)
> at
> org.apache.ignite.internal.util.future.GridFutureAdapter.unblock(GridFutureAdapter.java:347)
> at
> org.apache.ignite.internal.util.future.GridFutureAdapter.unblockAll(GridFutureAdapter.java:335)
> at
>
[jira] [Commented] (IGNITE-8424) Sort directories in readCacheConfigurations() to ensure consistent caches start
[
https://issues.apache.org/jira/browse/IGNITE-8424?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16462990#comment-16462990
]
Ivan Daschinskiy commented on IGNITE-8424:
--
[~agoncharuk] Tests run seems to be ok for me. Could you review my patch,
please?
> Sort directories in readCacheConfigurations() to ensure consistent caches
> start
> ---
>
> Key: IGNITE-8424
> URL: https://issues.apache.org/jira/browse/IGNITE-8424
> Project: Ignite
> Issue Type: Improvement
>Reporter: Alexey Goncharuk
>Assignee: Ivan Daschinskiy
>Priority: Critical
>
> {{listFiles()}} may return different folders order on different nodes. We
> should sort directories just to be sure that this code is robust for cases
> when caches with the same names got into different cache groups.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (IGNITE-8424) Sort directories in readCacheConfigurations() to ensure consistent caches start
[
https://issues.apache.org/jira/browse/IGNITE-8424?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ivan Daschinskiy updated IGNITE-8424:
-
Priority: Critical (was: Major)
> Sort directories in readCacheConfigurations() to ensure consistent caches
> start
> ---
>
> Key: IGNITE-8424
> URL: https://issues.apache.org/jira/browse/IGNITE-8424
> Project: Ignite
> Issue Type: Improvement
>Reporter: Alexey Goncharuk
>Assignee: Ivan Daschinskiy
>Priority: Critical
>
> {{listFiles()}} may return different folders order on different nodes. We
> should sort directories just to be sure that this code is robust for cases
> when caches with the same names got into different cache groups.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Assigned] (IGNITE-8424) Sort directories in readCacheConfigurations() to ensure consistent caches start
[
https://issues.apache.org/jira/browse/IGNITE-8424?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ivan Daschinskiy reassigned IGNITE-8424:
Assignee: Ivan Daschinskiy
> Sort directories in readCacheConfigurations() to ensure consistent caches
> start
> ---
>
> Key: IGNITE-8424
> URL: https://issues.apache.org/jira/browse/IGNITE-8424
> Project: Ignite
> Issue Type: Improvement
>Reporter: Alexey Goncharuk
>Assignee: Ivan Daschinskiy
>Priority: Major
>
> {{listFiles()}} may return different folders order on different nodes. We
> should sort directories just to be sure that this code is robust for cases
> when caches with the same names got into different cache groups.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (IGNITE-8429) Unexpected error during incorrect WAL segment decompression, causes node termination.
[ https://issues.apache.org/jira/browse/IGNITE-8429?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ivan Daschinskiy updated IGNITE-8429: - Priority: Critical (was: Major) > Unexpected error during incorrect WAL segment decompression, causes node > termination. > - > > Key: IGNITE-8429 > URL: https://issues.apache.org/jira/browse/IGNITE-8429 > Project: Ignite > Issue Type: Bug > Components: persistence >Affects Versions: 2.5 >Reporter: Ivan Daschinskiy >Priority: Critical > Labels: WAL > Fix For: 2.5 > > > File decompressor failure due to incorrect (zero-length) archived segment. > 2018-04-30 00:00:02.811 > [ERROR][wal-file-decompressor%DPL_GRID%DplGridNodeName][org.apache.ignite.Ignite] > Critical system error detected. Will be handled accordingly to configured > handler [hnd=class o.a.i.failure.StopNodeOrHaltFailureHandler, > failureCtx=FailureContext [type=SYSTEM_WORKER_TERMINATION, > err=java.lang.IllegalStateException: Thread > wal-file-decompressor%DPL_GRID%DplGridNodeName is terminated unexpectedly]] > java.lang.IllegalStateException: Thread > wal-file-decompressor%DPL_GRID%DplGridNodeName is terminated unexpectedly > at > org.apache.ignite.internal.processors.cache.persistence.wal.FileWriteAheadLogManager$FileDecompressor.run(FileWriteAheadLogManager.java:2104) > 2018-04-30 00:00:02.812 > [ERROR][wal-file-decompressor%DPL_GRID%DplGridNodeName][org.apache.ignite.Ignite] > JVM will be halted immediately due to the failure: > [failureCtx=FailureContext [type=SYSTEM_WORKER_TERMINATION, > err=java.lang.IllegalStateException: Thread > wal-file-decompressor%DPL_GRID%DplGridNodeName is terminated unexpectedly]] > touch 0754.wal > zip 0754.wal.zip 0754.wal > ls -l > -rw-rw-r-- 1 dmitriy dmitriy 0 май 1 16:40 0754.wal > -rw-rw-r-- 1 dmitriy dmitriy 190 май 1 16:46 0754.wal.zip > Archive: /tmp/temp/0754.wal.zip > Length MethodSize CmprDateTime CRC-32 Name > -- --- -- - >0 Stored0 0% 2018-05-01 16:40 0754.wal > --- ------ >00 0%1 file > We should softly handle this situation: print message in log and continue the > decompression with next segment. > We also should handle "skipped" segments and don't delete them in > deleteObsoleteRawSegments(). -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-8429) Unexpected error during incorrect WAL segment decompression, causes node termination.
[ https://issues.apache.org/jira/browse/IGNITE-8429?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ivan Daschinskiy updated IGNITE-8429: - Description: File decompressor failure due to incorrect (zero-length) archived segment. 2018-04-30 00:00:02.811 [ERROR][wal-file-decompressor%DPL_GRID%DplGridNodeName][org.apache.ignite.Ignite] Critical system error detected. Will be handled accordingly to configured handler [hnd=class o.a.i.failure.StopNodeOrHaltFailureHandler, failureCtx=FailureContext [type=SYSTEM_WORKER_TERMINATION, err=java.lang.IllegalStateException: Thread wal-file-decompressor%DPL_GRID%DplGridNodeName is terminated unexpectedly]] java.lang.IllegalStateException: Thread wal-file-decompressor%DPL_GRID%DplGridNodeName is terminated unexpectedly at org.apache.ignite.internal.processors.cache.persistence.wal.FileWriteAheadLogManager$FileDecompressor.run(FileWriteAheadLogManager.java:2104) 2018-04-30 00:00:02.812 [ERROR][wal-file-decompressor%DPL_GRID%DplGridNodeName][org.apache.ignite.Ignite] JVM will be halted immediately due to the failure: [failureCtx=FailureContext [type=SYSTEM_WORKER_TERMINATION, err=java.lang.IllegalStateException: Thread wal-file-decompressor%DPL_GRID%DplGridNodeName is terminated unexpectedly]] touch 0754.wal zip 0754.wal.zip 0754.wal ls -l -rw-rw-r-- 1 dmitriy dmitriy 0 май 1 16:40 0754.wal -rw-rw-r-- 1 dmitriy dmitriy 190 май 1 16:46 0754.wal.zip Archive: /tmp/temp/0754.wal.zip Length MethodSize CmprDateTime CRC-32 Name -- --- -- - 0 Stored0 0% 2018-05-01 16:40 0754.wal --- ------ 00 0%1 file We should softly handle this situation: print message in log and continue the decompression with next segment. We also should handle "skipped" segments and don't delete them in deleteObsoleteRawSegments(). was: File decompressor failure due to incorrect (zero-length) archived segment. 2018-04-30 00:00:02.811 [ERROR][wal-file-decompressor%DPL_GRID%DplGridNodeName][org.apache.ignite.Ignite] Critical system error detected. Will be handled accordingly to configured handler [hnd=class o.a.i.failure.StopNodeOrHaltFailureHandler, failureCtx=FailureContext [type=SYSTEM_WORKER_TERMINATION, err=java.lang.IllegalStateException: Thread wal-file-decompressor%DPL_GRID%DplGridNodeName is terminated unexpectedly]] java.lang.IllegalStateException: Thread wal-file-decompressor%DPL_GRID%DplGridNodeName is terminated unexpectedly at org.apache.ignite.internal.processors.cache.persistence.wal.FileWriteAheadLogManager$FileDecompressor.run(FileWriteAheadLogManager.java:2104) 2018-04-30 00:00:02.812 [ERROR][wal-file-decompressor%DPL_GRID%DplGridNodeName][org.apache.ignite.Ignite] JVM will be halted immediately due to the failure: [failureCtx=FailureContext [type=SYSTEM_WORKER_TERMINATION, err=java.lang.IllegalStateException: Thread wal-file-decompressor%DPL_GRID%DplGridNodeName is terminated unexpectedly]] touch 0754.wal zip 0754.wal.zip 0754.wal ls -l -rw-rw-r-- 1 dmitriy dmitriy 0 май 1 16:40 0754.wal -rw-rw-r-- 1 dmitriy dmitriy 190 май 1 16:46 0754.wal.zip Archive: /tmp/temp/0754.wal.zip Length MethodSize CmprDateTime CRC-32 Name -- --- -- - 0 Stored0 0% 2018-05-01 16:40 0754.wal --- ------ 00 0%1 file We should softly handle this situation: print message in log and continue the compression with next segment. We also should handle "skipped" segments and don't delete them in deleteObsoleteRawSegments(). > Unexpected error during incorrect WAL segment decompression, causes node > termination. > - > > Key: IGNITE-8429 > URL: https://issues.apache.org/jira/browse/IGNITE-8429 > Project: Ignite > Issue Type: Bug > Components: persistence >Affects Versions: 2.5 >Reporter: Ivan Daschinskiy >Priority: Major > Labels: WAL > Fix For: 2.5 > > > File decompressor failure due to incorrect (zero-length) archived segment. > 2018-04-30 00:00:02.811 > [ERROR][wal-file-decompressor%DPL_GRID%DplGridNodeName][org.apache.ignite.Ignite] > Critical system error detected. Will be handled accordingly to configured > handler [hnd=class o.a.i.failure.StopNodeOrHaltFailureHandler, > failureCtx=FailureContext
[jira] [Updated] (IGNITE-8429) Unexpected error during incorrect WAL segment decompression, causes node termination.
[ https://issues.apache.org/jira/browse/IGNITE-8429?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ivan Daschinskiy updated IGNITE-8429: - Labels: WAL (was: ) > Unexpected error during incorrect WAL segment decompression, causes node > termination. > - > > Key: IGNITE-8429 > URL: https://issues.apache.org/jira/browse/IGNITE-8429 > Project: Ignite > Issue Type: Bug > Components: persistence >Affects Versions: 2.5 >Reporter: Ivan Daschinskiy >Priority: Major > Labels: WAL > Fix For: 2.5 > > > File decompressor failure due to incorrect (zero-length) archived segment. > 2018-04-30 00:00:02.811 > [ERROR][wal-file-decompressor%DPL_GRID%DplGridNodeName][org.apache.ignite.Ignite] > Critical system error detected. Will be handled accordingly to configured > handler [hnd=class o.a.i.failure.StopNodeOrHaltFailureHandler, > failureCtx=FailureContext [type=SYSTEM_WORKER_TERMINATION, > err=java.lang.IllegalStateException: Thread > wal-file-decompressor%DPL_GRID%DplGridNodeName is terminated unexpectedly]] > java.lang.IllegalStateException: Thread > wal-file-decompressor%DPL_GRID%DplGridNodeName is terminated unexpectedly > at > org.apache.ignite.internal.processors.cache.persistence.wal.FileWriteAheadLogManager$FileDecompressor.run(FileWriteAheadLogManager.java:2104) > 2018-04-30 00:00:02.812 > [ERROR][wal-file-decompressor%DPL_GRID%DplGridNodeName][org.apache.ignite.Ignite] > JVM will be halted immediately due to the failure: > [failureCtx=FailureContext [type=SYSTEM_WORKER_TERMINATION, > err=java.lang.IllegalStateException: Thread > wal-file-decompressor%DPL_GRID%DplGridNodeName is terminated unexpectedly]] > touch 0754.wal > zip 0754.wal.zip 0754.wal > ls -l > -rw-rw-r-- 1 dmitriy dmitriy 0 май 1 16:40 0754.wal > -rw-rw-r-- 1 dmitriy dmitriy 190 май 1 16:46 0754.wal.zip > Archive: /tmp/temp/0754.wal.zip > Length MethodSize CmprDateTime CRC-32 Name > -- --- -- - >0 Stored0 0% 2018-05-01 16:40 0754.wal > --- ------ >00 0%1 file > We should softly handle this situation: print message in log and continue the > compression with next segment. > We also should handle "skipped" segments and don't delete them in > deleteObsoleteRawSegments(). -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-8429) Unexpected error during incorrect WAL segment decompression, causes node termination.
Ivan Daschinskiy created IGNITE-8429: Summary: Unexpected error during incorrect WAL segment decompression, causes node termination. Key: IGNITE-8429 URL: https://issues.apache.org/jira/browse/IGNITE-8429 Project: Ignite Issue Type: Bug Components: persistence Affects Versions: 2.5 Reporter: Ivan Daschinskiy Fix For: 2.5 File decompressor failure due to incorrect (zero-length) archived segment. 2018-04-30 00:00:02.811 [ERROR][wal-file-decompressor%DPL_GRID%DplGridNodeName][org.apache.ignite.Ignite] Critical system error detected. Will be handled accordingly to configured handler [hnd=class o.a.i.failure.StopNodeOrHaltFailureHandler, failureCtx=FailureContext [type=SYSTEM_WORKER_TERMINATION, err=java.lang.IllegalStateException: Thread wal-file-decompressor%DPL_GRID%DplGridNodeName is terminated unexpectedly]] java.lang.IllegalStateException: Thread wal-file-decompressor%DPL_GRID%DplGridNodeName is terminated unexpectedly at org.apache.ignite.internal.processors.cache.persistence.wal.FileWriteAheadLogManager$FileDecompressor.run(FileWriteAheadLogManager.java:2104) 2018-04-30 00:00:02.812 [ERROR][wal-file-decompressor%DPL_GRID%DplGridNodeName][org.apache.ignite.Ignite] JVM will be halted immediately due to the failure: [failureCtx=FailureContext [type=SYSTEM_WORKER_TERMINATION, err=java.lang.IllegalStateException: Thread wal-file-decompressor%DPL_GRID%DplGridNodeName is terminated unexpectedly]] touch 0754.wal zip 0754.wal.zip 0754.wal ls -l -rw-rw-r-- 1 dmitriy dmitriy 0 май 1 16:40 0754.wal -rw-rw-r-- 1 dmitriy dmitriy 190 май 1 16:46 0754.wal.zip Archive: /tmp/temp/0754.wal.zip Length MethodSize CmprDateTime CRC-32 Name -- --- -- - 0 Stored0 0% 2018-05-01 16:40 0754.wal --- ------ 00 0%1 file We should softly handle this situation: print message in log and continue the compression with next segment. We also should handle "skipped" segments and don't delete them in deleteObsoleteRawSegments(). -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-7912) control.sh script should show used WAL-segments
[ https://issues.apache.org/jira/browse/IGNITE-7912?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16461273#comment-16461273 ] Ivan Daschinskiy commented on IGNITE-7912: -- Merged latest changes and added newest TC build. Tests seems to be ok. > control.sh script should show used WAL-segments > --- > > Key: IGNITE-7912 > URL: https://issues.apache.org/jira/browse/IGNITE-7912 > Project: Ignite > Issue Type: Improvement >Reporter: Sergey Filatov >Assignee: Ivan Daschinskiy >Priority: Minor > > We have to erase wal archive because wal archive can grow large and we must > have safe way to remove unused segments to free disk space. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-8075) .NET: setRollbackOnTopologyChangeTimeout, withLabel, localActiveTransactions, setTxTimeoutOnPartitionMapExchange
[ https://issues.apache.org/jira/browse/IGNITE-8075?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16456713#comment-16456713 ] Ivan Daschinskiy commented on IGNITE-8075: -- [~ptupitsyn] Done. > .NET: setRollbackOnTopologyChangeTimeout, withLabel, localActiveTransactions, > setTxTimeoutOnPartitionMapExchange > > > Key: IGNITE-8075 > URL: https://issues.apache.org/jira/browse/IGNITE-8075 > Project: Ignite > Issue Type: Improvement >Affects Versions: 2.4 >Reporter: Alexei Scherbakov >Assignee: Ivan Daschinskiy >Priority: Major > Fix For: 2.6 > > > Neet to add new methods as part of .NET API: > org.apache.ignite.configuration.TransactionConfiguration#txTimeoutOnPartitionMapExchange > - timeout for automatic rollback on exchange. > org.apache.ignite.IgniteTransactions#withLabel - tx label > org.apache.ignite.IgniteTransactions#localActiveTransactions - list of local > active transactions. > org.apache.ignite.IgniteCluster#setTxTimeoutOnPartitionMapExchange > Java implementation is currently available at a branch [1] > [1] https://github.com/gridgain/apache-ignite/tree/ignite-6827-2 -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-8075) .NET: setRollbackOnTopologyChangeTimeout, withLabel, localActiveTransactions, setTxTimeoutOnPartitionMapExchange
[ https://issues.apache.org/jira/browse/IGNITE-8075?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16456707#comment-16456707 ] Ivan Daschinskiy commented on IGNITE-8075: -- [~ptupitsyn] Yes, this is too much. Just iteration over _col and Dispose() is enough. > .NET: setRollbackOnTopologyChangeTimeout, withLabel, localActiveTransactions, > setTxTimeoutOnPartitionMapExchange > > > Key: IGNITE-8075 > URL: https://issues.apache.org/jira/browse/IGNITE-8075 > Project: Ignite > Issue Type: Improvement >Affects Versions: 2.4 >Reporter: Alexei Scherbakov >Assignee: Ivan Daschinskiy >Priority: Major > Fix For: 2.6 > > > Neet to add new methods as part of .NET API: > org.apache.ignite.configuration.TransactionConfiguration#txTimeoutOnPartitionMapExchange > - timeout for automatic rollback on exchange. > org.apache.ignite.IgniteTransactions#withLabel - tx label > org.apache.ignite.IgniteTransactions#localActiveTransactions - list of local > active transactions. > org.apache.ignite.IgniteCluster#setTxTimeoutOnPartitionMapExchange > Java implementation is currently available at a branch [1] > [1] https://github.com/gridgain/apache-ignite/tree/ignite-6827-2 -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-8075) .NET: setRollbackOnTopologyChangeTimeout, withLabel, localActiveTransactions, setTxTimeoutOnPartitionMapExchange
[ https://issues.apache.org/jira/browse/IGNITE-8075?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16456690#comment-16456690 ] Ivan Daschinskiy commented on IGNITE-8075: -- [~ptupitsyn] I've corrected this (remove try catch block) . One more TC run is required? > .NET: setRollbackOnTopologyChangeTimeout, withLabel, localActiveTransactions, > setTxTimeoutOnPartitionMapExchange > > > Key: IGNITE-8075 > URL: https://issues.apache.org/jira/browse/IGNITE-8075 > Project: Ignite > Issue Type: Improvement >Affects Versions: 2.4 >Reporter: Alexei Scherbakov >Assignee: Ivan Daschinskiy >Priority: Major > Fix For: 2.6 > > > Neet to add new methods as part of .NET API: > org.apache.ignite.configuration.TransactionConfiguration#txTimeoutOnPartitionMapExchange > - timeout for automatic rollback on exchange. > org.apache.ignite.IgniteTransactions#withLabel - tx label > org.apache.ignite.IgniteTransactions#localActiveTransactions - list of local > active transactions. > org.apache.ignite.IgniteCluster#setTxTimeoutOnPartitionMapExchange > Java implementation is currently available at a branch [1] > [1] https://github.com/gridgain/apache-ignite/tree/ignite-6827-2 -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-8075) .NET: setRollbackOnTopologyChangeTimeout, withLabel, localActiveTransactions, setTxTimeoutOnPartitionMapExchange
[ https://issues.apache.org/jira/browse/IGNITE-8075?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16455460#comment-16455460 ] Ivan Daschinskiy commented on IGNITE-8075: -- Ok, I'll remove it. Do you have other remarks? > .NET: setRollbackOnTopologyChangeTimeout, withLabel, localActiveTransactions, > setTxTimeoutOnPartitionMapExchange > > > Key: IGNITE-8075 > URL: https://issues.apache.org/jira/browse/IGNITE-8075 > Project: Ignite > Issue Type: Improvement >Affects Versions: 2.4 >Reporter: Alexei Scherbakov >Assignee: Ivan Daschinskiy >Priority: Major > Fix For: 2.6 > > > Neet to add new methods as part of .NET API: > org.apache.ignite.configuration.TransactionConfiguration#txTimeoutOnPartitionMapExchange > - timeout for automatic rollback on exchange. > org.apache.ignite.IgniteTransactions#withLabel - tx label > org.apache.ignite.IgniteTransactions#localActiveTransactions - list of local > active transactions. > org.apache.ignite.IgniteCluster#setTxTimeoutOnPartitionMapExchange > Java implementation is currently available at a branch [1] > [1] https://github.com/gridgain/apache-ignite/tree/ignite-6827-2 -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-8075) .NET: setRollbackOnTopologyChangeTimeout, withLabel, localActiveTransactions, setTxTimeoutOnPartitionMapExchange
[ https://issues.apache.org/jira/browse/IGNITE-8075?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16454420#comment-16454420 ] Ivan Daschinskiy commented on IGNITE-8075: -- [~ptupitsyn] Hi! Here are latest TC build results. It seems OK for me. However, there is one fxcop warning about too common catch and swallow exceptions in Dispose in TransactionCollectionImpl. I'm considering this as false positive. Dispose should not throw any error and I wanna dispose all transactions in any circumstances. Your thoughts? > .NET: setRollbackOnTopologyChangeTimeout, withLabel, localActiveTransactions, > setTxTimeoutOnPartitionMapExchange > > > Key: IGNITE-8075 > URL: https://issues.apache.org/jira/browse/IGNITE-8075 > Project: Ignite > Issue Type: Improvement >Affects Versions: 2.4 >Reporter: Alexei Scherbakov >Assignee: Ivan Daschinskiy >Priority: Major > Fix For: 2.6 > > > Neet to add new methods as part of .NET API: > org.apache.ignite.configuration.TransactionConfiguration#txTimeoutOnPartitionMapExchange > - timeout for automatic rollback on exchange. > org.apache.ignite.IgniteTransactions#withLabel - tx label > org.apache.ignite.IgniteTransactions#localActiveTransactions - list of local > active transactions. > org.apache.ignite.IgniteCluster#setTxTimeoutOnPartitionMapExchange > Java implementation is currently available at a branch [1] > [1] https://github.com/gridgain/apache-ignite/tree/ignite-6827-2 -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-8075) .NET: setRollbackOnTopologyChangeTimeout, withLabel, localActiveTransactions, setTxTimeoutOnPartitionMapExchange
[ https://issues.apache.org/jira/browse/IGNITE-8075?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16452081#comment-16452081 ] Ivan Daschinskiy commented on IGNITE-8075: -- [~ptupitsyn] Thank you for your review. I've implemented your suggestions, now waiting for TC run completion. > .NET: setRollbackOnTopologyChangeTimeout, withLabel, localActiveTransactions, > setTxTimeoutOnPartitionMapExchange > > > Key: IGNITE-8075 > URL: https://issues.apache.org/jira/browse/IGNITE-8075 > Project: Ignite > Issue Type: Improvement >Affects Versions: 2.4 >Reporter: Alexei Scherbakov >Assignee: Ivan Daschinskiy >Priority: Major > Fix For: 2.6 > > > Neet to add new methods as part of .NET API: > org.apache.ignite.configuration.TransactionConfiguration#txTimeoutOnPartitionMapExchange > - timeout for automatic rollback on exchange. > org.apache.ignite.IgniteTransactions#withLabel - tx label > org.apache.ignite.IgniteTransactions#localActiveTransactions - list of local > active transactions. > org.apache.ignite.IgniteCluster#setTxTimeoutOnPartitionMapExchange > Java implementation is currently available at a branch [1] > [1] https://github.com/gridgain/apache-ignite/tree/ignite-6827-2 -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Comment Edited] (IGNITE-8075) .NET: setRollbackOnTopologyChangeTimeout, withLabel, localActiveTransactions, setTxTimeoutOnPartitionMapExchange
[ https://issues.apache.org/jira/browse/IGNITE-8075?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16451648#comment-16451648 ] Ivan Daschinskiy edited comment on IGNITE-8075 at 4/25/18 4:25 AM: --- Guys. I don't mentioned, but now I'm a little bit embarrased about this fact. Why we use custom atomic counter instead of transaction's xid? Also, [~NIzhikov] recently commited ability to suspend and resume transactions. Should we add this functionality? was (Author: ivandasch): Guys. I don't mentioned, but now I'm a little bit embarrased about this fact. Why we use custom atomic counter instead of transaction's xid? > .NET: setRollbackOnTopologyChangeTimeout, withLabel, localActiveTransactions, > setTxTimeoutOnPartitionMapExchange > > > Key: IGNITE-8075 > URL: https://issues.apache.org/jira/browse/IGNITE-8075 > Project: Ignite > Issue Type: Improvement >Affects Versions: 2.4 >Reporter: Alexei Scherbakov >Assignee: Ivan Daschinskiy >Priority: Major > Fix For: 2.6 > > > Neet to add new methods as part of .NET API: > org.apache.ignite.configuration.TransactionConfiguration#txTimeoutOnPartitionMapExchange > - timeout for automatic rollback on exchange. > org.apache.ignite.IgniteTransactions#withLabel - tx label > org.apache.ignite.IgniteTransactions#localActiveTransactions - list of local > active transactions. > org.apache.ignite.IgniteCluster#setTxTimeoutOnPartitionMapExchange > Java implementation is currently available at a branch [1] > [1] https://github.com/gridgain/apache-ignite/tree/ignite-6827-2 -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-8075) .NET: setRollbackOnTopologyChangeTimeout, withLabel, localActiveTransactions, setTxTimeoutOnPartitionMapExchange
[ https://issues.apache.org/jira/browse/IGNITE-8075?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16451648#comment-16451648 ] Ivan Daschinskiy commented on IGNITE-8075: -- Guys. I don't mentioned, but now I'm a little bit embarrased about this fact. Why we use custom atomic counter instead of transaction's xid? > .NET: setRollbackOnTopologyChangeTimeout, withLabel, localActiveTransactions, > setTxTimeoutOnPartitionMapExchange > > > Key: IGNITE-8075 > URL: https://issues.apache.org/jira/browse/IGNITE-8075 > Project: Ignite > Issue Type: Improvement >Affects Versions: 2.4 >Reporter: Alexei Scherbakov >Assignee: Ivan Daschinskiy >Priority: Major > Fix For: 2.6 > > > Neet to add new methods as part of .NET API: > org.apache.ignite.configuration.TransactionConfiguration#txTimeoutOnPartitionMapExchange > - timeout for automatic rollback on exchange. > org.apache.ignite.IgniteTransactions#withLabel - tx label > org.apache.ignite.IgniteTransactions#localActiveTransactions - list of local > active transactions. > org.apache.ignite.IgniteCluster#setTxTimeoutOnPartitionMapExchange > Java implementation is currently available at a branch [1] > [1] https://github.com/gridgain/apache-ignite/tree/ignite-6827-2 -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Comment Edited] (IGNITE-8075) .NET: setRollbackOnTopologyChangeTimeout, withLabel, localActiveTransactions, setTxTimeoutOnPartitionMapExchange
[ https://issues.apache.org/jira/browse/IGNITE-8075?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16451237#comment-16451237 ] Ivan Daschinskiy edited comment on IGNITE-8075 at 4/24/18 10:36 PM: To overcome this difficulties, now GetActiveLocalTransactions return read only disposable collection. Now user can simply wrap call of this method in "using", do whatever he/she wants and don't care about disposing bunch of transactions. was (Author: ivandasch): To overcome this difficulties, I can implement sealed internal disposable list of transactions and return it instead of ordinary list. > .NET: setRollbackOnTopologyChangeTimeout, withLabel, localActiveTransactions, > setTxTimeoutOnPartitionMapExchange > > > Key: IGNITE-8075 > URL: https://issues.apache.org/jira/browse/IGNITE-8075 > Project: Ignite > Issue Type: Improvement >Affects Versions: 2.4 >Reporter: Alexei Scherbakov >Assignee: Ivan Daschinskiy >Priority: Major > Fix For: 2.6 > > > Neet to add new methods as part of .NET API: > org.apache.ignite.configuration.TransactionConfiguration#txTimeoutOnPartitionMapExchange > - timeout for automatic rollback on exchange. > org.apache.ignite.IgniteTransactions#withLabel - tx label > org.apache.ignite.IgniteTransactions#localActiveTransactions - list of local > active transactions. > org.apache.ignite.IgniteCluster#setTxTimeoutOnPartitionMapExchange > Java implementation is currently available at a branch [1] > [1] https://github.com/gridgain/apache-ignite/tree/ignite-6827-2 -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-8075) .NET: setRollbackOnTopologyChangeTimeout, withLabel, localActiveTransactions, setTxTimeoutOnPartitionMapExchange
[ https://issues.apache.org/jira/browse/IGNITE-8075?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16451237#comment-16451237 ] Ivan Daschinskiy commented on IGNITE-8075: -- To overcome this difficulties, I can implement sealed internal disposable list of transactions and return it instead of ordinary list. > .NET: setRollbackOnTopologyChangeTimeout, withLabel, localActiveTransactions, > setTxTimeoutOnPartitionMapExchange > > > Key: IGNITE-8075 > URL: https://issues.apache.org/jira/browse/IGNITE-8075 > Project: Ignite > Issue Type: Improvement >Affects Versions: 2.4 >Reporter: Alexei Scherbakov >Assignee: Ivan Daschinskiy >Priority: Major > Fix For: 2.6 > > > Neet to add new methods as part of .NET API: > org.apache.ignite.configuration.TransactionConfiguration#txTimeoutOnPartitionMapExchange > - timeout for automatic rollback on exchange. > org.apache.ignite.IgniteTransactions#withLabel - tx label > org.apache.ignite.IgniteTransactions#localActiveTransactions - list of local > active transactions. > org.apache.ignite.IgniteCluster#setTxTimeoutOnPartitionMapExchange > Java implementation is currently available at a branch [1] > [1] https://github.com/gridgain/apache-ignite/tree/ignite-6827-2 -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-8075) .NET: setRollbackOnTopologyChangeTimeout, withLabel, localActiveTransactions, setTxTimeoutOnPartitionMapExchange
[ https://issues.apache.org/jira/browse/IGNITE-8075?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16450434#comment-16450434 ] Ivan Daschinskiy commented on IGNITE-8075: -- [~ptupitsyn] >>> _Also, assertion in registerTx will fail if we call >>> GetLocalActiveTransactions twice._ I suppose that won't. registerTx autoicrement atomic counter TX_ID_GEN. It should not fail with assertion. _the big problem here is that we call registerTx in Java, which means that user has to manually Dispose every returned transaction_ Yes, I agree. But the same is for ordinary transaction, isn't it? > .NET: setRollbackOnTopologyChangeTimeout, withLabel, localActiveTransactions, > setTxTimeoutOnPartitionMapExchange > > > Key: IGNITE-8075 > URL: https://issues.apache.org/jira/browse/IGNITE-8075 > Project: Ignite > Issue Type: Improvement >Affects Versions: 2.4 >Reporter: Alexei Scherbakov >Assignee: Ivan Daschinskiy >Priority: Major > Fix For: 2.6 > > > Neet to add new methods as part of .NET API: > org.apache.ignite.configuration.TransactionConfiguration#txTimeoutOnPartitionMapExchange > - timeout for automatic rollback on exchange. > org.apache.ignite.IgniteTransactions#withLabel - tx label > org.apache.ignite.IgniteTransactions#localActiveTransactions - list of local > active transactions. > org.apache.ignite.IgniteCluster#setTxTimeoutOnPartitionMapExchange > Java implementation is currently available at a branch [1] > [1] https://github.com/gridgain/apache-ignite/tree/ignite-6827-2 -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Comment Edited] (IGNITE-8075) .NET: setRollbackOnTopologyChangeTimeout, withLabel, localActiveTransactions, setTxTimeoutOnPartitionMapExchange
[ https://issues.apache.org/jira/browse/IGNITE-8075?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16450308#comment-16450308 ] Ivan Daschinskiy edited comment on IGNITE-8075 at 4/24/18 6:11 PM: --- [~ptupitsyn]Thank you for a review. 1. Yep, corresponding Java API has only setter. 2. I simply forgot to change back after reimplementing in another way. 3. Ok, got it. 4. Ok, got it. I'ver already corrected this. was (Author: ivandasch): [~ptupitsyn]Thank you for a review. 1. Yep, corresponding Java API has only setter. 2. I simply forgot to change back after reimplementing in another way. 3. Ok, got it. 4. Ok, got it. I'm gonna correct this tonight. > .NET: setRollbackOnTopologyChangeTimeout, withLabel, localActiveTransactions, > setTxTimeoutOnPartitionMapExchange > > > Key: IGNITE-8075 > URL: https://issues.apache.org/jira/browse/IGNITE-8075 > Project: Ignite > Issue Type: Improvement >Affects Versions: 2.4 >Reporter: Alexei Scherbakov >Assignee: Ivan Daschinskiy >Priority: Major > Fix For: 2.6 > > > Neet to add new methods as part of .NET API: > org.apache.ignite.configuration.TransactionConfiguration#txTimeoutOnPartitionMapExchange > - timeout for automatic rollback on exchange. > org.apache.ignite.IgniteTransactions#withLabel - tx label > org.apache.ignite.IgniteTransactions#localActiveTransactions - list of local > active transactions. > org.apache.ignite.IgniteCluster#setTxTimeoutOnPartitionMapExchange > Java implementation is currently available at a branch [1] > [1] https://github.com/gridgain/apache-ignite/tree/ignite-6827-2 -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-8075) .NET: setRollbackOnTopologyChangeTimeout, withLabel, localActiveTransactions, setTxTimeoutOnPartitionMapExchange
[ https://issues.apache.org/jira/browse/IGNITE-8075?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16450308#comment-16450308 ] Ivan Daschinskiy commented on IGNITE-8075: -- [~ptupitsyn]Thank you for a review. 1. Yep, corresponding Java API has only setter. 2. I simply forgot to change back after reimplementing in another way. 3. Ok, got it. 4. Ok, got it. I'm gonna correct this tonight. > .NET: setRollbackOnTopologyChangeTimeout, withLabel, localActiveTransactions, > setTxTimeoutOnPartitionMapExchange > > > Key: IGNITE-8075 > URL: https://issues.apache.org/jira/browse/IGNITE-8075 > Project: Ignite > Issue Type: Improvement >Affects Versions: 2.4 >Reporter: Alexei Scherbakov >Assignee: Ivan Daschinskiy >Priority: Major > Fix For: 2.6 > > > Neet to add new methods as part of .NET API: > org.apache.ignite.configuration.TransactionConfiguration#txTimeoutOnPartitionMapExchange > - timeout for automatic rollback on exchange. > org.apache.ignite.IgniteTransactions#withLabel - tx label > org.apache.ignite.IgniteTransactions#localActiveTransactions - list of local > active transactions. > org.apache.ignite.IgniteCluster#setTxTimeoutOnPartitionMapExchange > Java implementation is currently available at a branch [1] > [1] https://github.com/gridgain/apache-ignite/tree/ignite-6827-2 -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Assigned] (IGNITE-7896) Files of evicted partitions are not removed from disk storage
[ https://issues.apache.org/jira/browse/IGNITE-7896?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ivan Daschinskiy reassigned IGNITE-7896: Assignee: Ivan Daschinskiy > Files of evicted partitions are not removed from disk storage > - > > Key: IGNITE-7896 > URL: https://issues.apache.org/jira/browse/IGNITE-7896 > Project: Ignite > Issue Type: Bug >Reporter: Vladislav Pyatkov >Assignee: Ivan Daschinskiy >Priority: Major > Attachments: IgnitePdsRebalanceCompletionAndPartitionFilesTest.java > > > Look at test reproduction: > [^IgnitePdsRebalanceCompletionAndPartitionFilesTest.java] -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Comment Edited] (IGNITE-8075) .NET: setRollbackOnTopologyChangeTimeout, withLabel, localActiveTransactions, setTxTimeoutOnPartitionMapExchange
[ https://issues.apache.org/jira/browse/IGNITE-8075?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16449538#comment-16449538 ] Ivan Daschinskiy edited comment on IGNITE-8075 at 4/24/18 9:56 AM: --- TC run seems to be ok [~ptupitsyn] [~ascherbakov] Please, review my changes was (Author: ivandasch): TC run seems to be ok [~ptupitsyn] [[~ascherbakov] Please, review my changes > .NET: setRollbackOnTopologyChangeTimeout, withLabel, localActiveTransactions, > setTxTimeoutOnPartitionMapExchange > > > Key: IGNITE-8075 > URL: https://issues.apache.org/jira/browse/IGNITE-8075 > Project: Ignite > Issue Type: Improvement >Affects Versions: 2.4 >Reporter: Alexei Scherbakov >Assignee: Ivan Daschinskiy >Priority: Major > Fix For: 2.6 > > > Neet to add new methods as part of .NET API: > org.apache.ignite.configuration.TransactionConfiguration#txTimeoutOnPartitionMapExchange > - timeout for automatic rollback on exchange. > org.apache.ignite.IgniteTransactions#withLabel - tx label > org.apache.ignite.IgniteTransactions#localActiveTransactions - list of local > active transactions. > org.apache.ignite.IgniteCluster#setTxTimeoutOnPartitionMapExchange > Java implementation is currently available at a branch [1] > [1] https://github.com/gridgain/apache-ignite/tree/ignite-6827-2 -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Assigned] (IGNITE-4440) scalar misses bcastCall() in ScalarProjectionPimp class
[
https://issues.apache.org/jira/browse/IGNITE-4440?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ivan Daschinskiy reassigned IGNITE-4440:
Assignee: (was: Ivan Daschinskiy)
> scalar misses bcastCall() in ScalarProjectionPimp class
> ---
>
> Key: IGNITE-4440
> URL: https://issues.apache.org/jira/browse/IGNITE-4440
> Project: Ignite
> Issue Type: Improvement
>Affects Versions: 1.8
>Reporter: Alexander Prokofyev
>Priority: Minor
> Labels: scala
>
> It would be nice if ScalarProjectionPimp will add also bcastCall() method to
> ClusterGroup class like it already does with
> {code}
> def bcastRun(@Nullable r: Run, @Nullable p: NF) {
> value.ignite().compute(forPredicate(p)).broadcast(toRunnable(r))
> }
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-8203) Interrupting task can cause node fail with PersistenceStorageIOException.
[ https://issues.apache.org/jira/browse/IGNITE-8203?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16448150#comment-16448150 ] Ivan Daschinskiy commented on IGNITE-8203: -- TC run is OK for me, please review my ticket again > Interrupting task can cause node fail with PersistenceStorageIOException. > -- > > Key: IGNITE-8203 > URL: https://issues.apache.org/jira/browse/IGNITE-8203 > Project: Ignite > Issue Type: Bug > Components: persistence >Affects Versions: 2.4 >Reporter: Ivan Daschinskiy >Assignee: Ivan Daschinskiy >Priority: Major > Fix For: 2.6 > > Attachments: GridFailNodesOnCanceledTaskTest.java > > > Interrupting task with simple cache operations (i.e. get, put) can cause > PersistenceStorageIOException. Main cause of this failure is lack of proper > handling InterruptedException in FilePageStore.init() etc. This cause a throw > of ClosedByInterruptException by FileChannel.write() and so on. > PersistenceStorageIOException is a critical failure and typically makes a > node to stop. As a workaround, I would suggest to enable AsyncFileIO by > default until the fix was available. > A reproducer is attached. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Assigned] (IGNITE-8075) .NET: setRollbackOnTopologyChangeTimeout, withLabel, localActiveTransactions, setTxTimeoutOnPartitionMapExchange
[ https://issues.apache.org/jira/browse/IGNITE-8075?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ivan Daschinskiy reassigned IGNITE-8075: Assignee: Ivan Daschinskiy > .NET: setRollbackOnTopologyChangeTimeout, withLabel, localActiveTransactions, > setTxTimeoutOnPartitionMapExchange > > > Key: IGNITE-8075 > URL: https://issues.apache.org/jira/browse/IGNITE-8075 > Project: Ignite > Issue Type: Improvement >Affects Versions: 2.4 >Reporter: Alexei Scherbakov >Assignee: Ivan Daschinskiy >Priority: Major > Fix For: 2.6 > > > Neet to add new methods as part of .NET API: > org.apache.ignite.configuration.TransactionConfiguration#txTimeoutOnPartitionMapExchange > - timeout for automatic rollback on exchange. > org.apache.ignite.IgniteTransactions#withLabel - tx label > org.apache.ignite.IgniteTransactions#localActiveTransactions - list of local > active transactions. > org.apache.ignite.IgniteCluster#setTxTimeoutOnPartitionMapExchange > Java implementation is currently available at a branch [1] > [1] https://github.com/gridgain/apache-ignite/tree/ignite-6827-2 -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Assigned] (IGNITE-4440) scalar misses bcastCall() in ScalarProjectionPimp class
[
https://issues.apache.org/jira/browse/IGNITE-4440?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ivan Daschinskiy reassigned IGNITE-4440:
Assignee: Ivan Daschinskiy
> scalar misses bcastCall() in ScalarProjectionPimp class
> ---
>
> Key: IGNITE-4440
> URL: https://issues.apache.org/jira/browse/IGNITE-4440
> Project: Ignite
> Issue Type: Improvement
>Affects Versions: 1.8
>Reporter: Alexander Prokofyev
>Assignee: Ivan Daschinskiy
>Priority: Minor
> Labels: scala
>
> It would be nice if ScalarProjectionPimp will add also bcastCall() method to
> ClusterGroup class like it already does with
> {code}
> def bcastRun(@Nullable r: Run, @Nullable p: NF) {
> value.ignite().compute(forPredicate(p)).broadcast(toRunnable(r))
> }
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Assigned] (IGNITE-8070) .Net: FailureHandler should be added to Ignite configuration
[
https://issues.apache.org/jira/browse/IGNITE-8070?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ivan Daschinskiy reassigned IGNITE-8070:
Assignee: Ivan Daschinskiy
> .Net: FailureHandler should be added to Ignite configuration
>
>
> Key: IGNITE-8070
> URL: https://issues.apache.org/jira/browse/IGNITE-8070
> Project: Ignite
> Issue Type: Improvement
>Reporter: Andrey Gura
>Assignee: Ivan Daschinskiy
>Priority: Major
> Labels: iep-14
>
> {{IgniteConfiguration}} class was extended by new methods:
> {{setFailureHandler}} and {{getFailureHandler}}. Corresponding changes should
> be done in ignite .Net
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-7786) Changing baseline topology on cluster may have error in control.sh utility
[
https://issues.apache.org/jira/browse/IGNITE-7786?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16443764#comment-16443764
]
Ivan Daschinskiy commented on IGNITE-7786:
--
[~dpavlov] Run-all results are ready and they are ok for me.
> Changing baseline topology on cluster may have error in control.sh utility
> --
>
> Key: IGNITE-7786
> URL: https://issues.apache.org/jira/browse/IGNITE-7786
> Project: Ignite
> Issue Type: Bug
>Affects Versions: 2.3
>Reporter: Dmitry Sherstobitov
>Assignee: Ivan Daschinskiy
>Priority: Major
>
> Looks like there is hardcoded timeout for waiting result of change baseline
> operation
> In cluster there is following behaviour:
> # Set new baseline topology version
> # Utility starts, but then fails by connection error
> # Cluster successfully activated
> {code:java}
> ...Start node...
> ...Waiting for topology snapshot...
> > control_utility.sh --baseline version 9
> Control utility
> 2017 Copyright(C) Apache Software Foundation
> User: test
>
> Failed to set baseline with specified topology version.
> Connection to cluster failed.
> Error: Failed to perform request (connection failed): /IP
> ...few milliseconds later...
> > control_utility.sh --baseline version 9
> Control utility
> 2017 Copyright(C) Apache Software Foundation
> User: test
>
> Cluster state: active
> Current topology version: 9
> Baseline nodes:
> ConsistentID=node1, STATE=ONLINE
> ConsistentID=node10001, STATE=ONLINE
> ConsistentID=node2, STATE=ONLINE
> ConsistentID=node3, STATE=ONLINE
> ConsistentID=node4, STATE=ONLINE
>
> Number of baseline nodes: 5
> Other nodes not found.{code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-8021) Destroyed caches can be return to life by restart grid
[
https://issues.apache.org/jira/browse/IGNITE-8021?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16443575#comment-16443575
]
Ivan Daschinskiy commented on IGNITE-8021:
--
[~dpavlov] Latest TC run of my test fix has finished successfully. Link to it
is attached above.
> Destroyed caches can be return to life by restart grid
> --
>
> Key: IGNITE-8021
> URL: https://issues.apache.org/jira/browse/IGNITE-8021
> Project: Ignite
> Issue Type: Bug
>Reporter: Vladislav Pyatkov
>Assignee: Ivan Daschinskiy
>Priority: Major
> Fix For: 2.5
>
> Attachments: 8021-patch-for-patch, DstroedCacheReturnTest.java
>
>
> Cache configuration files stay stored on file system after invoke {{destroy}}
> method.
> By the reason after restart grid all removed caches are start.
>
> Look at the test [^DstroedCacheReturnTest.java]
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Comment Edited] (IGNITE-8203) Interrupting task can cause node fail with PersistenceStorageIOException.
[ https://issues.apache.org/jira/browse/IGNITE-8203?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16442582#comment-16442582 ] Ivan Daschinskiy edited comment on IGNITE-8203 at 4/18/18 2:27 PM: --- [~agoncharuk] Thank you for your review. I suppose I corrected issues you have mentioned and reran test locally with success. New TC run is pending. was (Author: ivandasch): [~agoncharuk] Thank you for your review. I suppose I corrected issues you have mentioned and rerun test locally. New TC run is pending. > Interrupting task can cause node fail with PersistenceStorageIOException. > -- > > Key: IGNITE-8203 > URL: https://issues.apache.org/jira/browse/IGNITE-8203 > Project: Ignite > Issue Type: Bug > Components: persistence >Affects Versions: 2.4 >Reporter: Ivan Daschinskiy >Assignee: Ivan Daschinskiy >Priority: Major > Fix For: 2.6 > > Attachments: GridFailNodesOnCanceledTaskTest.java > > > Interrupting task with simple cache operations (i.e. get, put) can cause > PersistenceStorageIOException. Main cause of this failure is lack of proper > handling InterruptedException in FilePageStore.init() etc. This cause a throw > of ClosedByInterruptException by FileChannel.write() and so on. > PersistenceStorageIOException is a critical failure and typically makes a > node to stop. As a workaround, I would suggest to enable AsyncFileIO by > default until the fix was available. > A reproducer is attached. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-8203) Interrupting task can cause node fail with PersistenceStorageIOException.
[ https://issues.apache.org/jira/browse/IGNITE-8203?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16442582#comment-16442582 ] Ivan Daschinskiy commented on IGNITE-8203: -- [~agoncharuk] Thank you for your review. I suppose I corrected issues you have mentioned and rerun test locally. New TC run is pending. > Interrupting task can cause node fail with PersistenceStorageIOException. > -- > > Key: IGNITE-8203 > URL: https://issues.apache.org/jira/browse/IGNITE-8203 > Project: Ignite > Issue Type: Bug > Components: persistence >Affects Versions: 2.4 >Reporter: Ivan Daschinskiy >Assignee: Ivan Daschinskiy >Priority: Major > Fix For: 2.6 > > Attachments: GridFailNodesOnCanceledTaskTest.java > > > Interrupting task with simple cache operations (i.e. get, put) can cause > PersistenceStorageIOException. Main cause of this failure is lack of proper > handling InterruptedException in FilePageStore.init() etc. This cause a throw > of ClosedByInterruptException by FileChannel.write() and so on. > PersistenceStorageIOException is a critical failure and typically makes a > node to stop. As a workaround, I would suggest to enable AsyncFileIO by > default until the fix was available. > A reproducer is attached. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-8021) Destroyed caches can be return to life by restart grid
[
https://issues.apache.org/jira/browse/IGNITE-8021?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16442486#comment-16442486
]
Ivan Daschinskiy commented on IGNITE-8021:
--
[~dpavlov] I suppose I fixed tests issues and currently my build is queued in
TC. Could you please code style etc. while build is pending?
> Destroyed caches can be return to life by restart grid
> --
>
> Key: IGNITE-8021
> URL: https://issues.apache.org/jira/browse/IGNITE-8021
> Project: Ignite
> Issue Type: Bug
>Reporter: Vladislav Pyatkov
>Assignee: Ivan Daschinskiy
>Priority: Major
> Fix For: 2.5
>
> Attachments: 8021-patch-for-patch, DstroedCacheReturnTest.java
>
>
> Cache configuration files stay stored on file system after invoke {{destroy}}
> method.
> By the reason after restart grid all removed caches are start.
>
> Look at the test [^DstroedCacheReturnTest.java]
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-7786) Changing baseline topology on cluster may have error in control.sh utility
[
https://issues.apache.org/jira/browse/IGNITE-7786?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16442472#comment-16442472
]
Ivan Daschinskiy commented on IGNITE-7786:
--
[~dpavlov] I understand your concerns. I will merge latest changes and rerun
run-all asap
> Changing baseline topology on cluster may have error in control.sh utility
> --
>
> Key: IGNITE-7786
> URL: https://issues.apache.org/jira/browse/IGNITE-7786
> Project: Ignite
> Issue Type: Bug
>Affects Versions: 2.3
>Reporter: Dmitry Sherstobitov
>Assignee: Ivan Daschinskiy
>Priority: Major
>
> Looks like there is hardcoded timeout for waiting result of change baseline
> operation
> In cluster there is following behaviour:
> # Set new baseline topology version
> # Utility starts, but then fails by connection error
> # Cluster successfully activated
> {code:java}
> ...Start node...
> ...Waiting for topology snapshot...
> > control_utility.sh --baseline version 9
> Control utility
> 2017 Copyright(C) Apache Software Foundation
> User: test
>
> Failed to set baseline with specified topology version.
> Connection to cluster failed.
> Error: Failed to perform request (connection failed): /IP
> ...few milliseconds later...
> > control_utility.sh --baseline version 9
> Control utility
> 2017 Copyright(C) Apache Software Foundation
> User: test
>
> Cluster state: active
> Current topology version: 9
> Baseline nodes:
> ConsistentID=node1, STATE=ONLINE
> ConsistentID=node10001, STATE=ONLINE
> ConsistentID=node2, STATE=ONLINE
> ConsistentID=node3, STATE=ONLINE
> ConsistentID=node4, STATE=ONLINE
>
> Number of baseline nodes: 5
> Other nodes not found.{code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-8021) Destroyed caches can be return to life by restart grid
[
https://issues.apache.org/jira/browse/IGNITE-8021?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16442391#comment-16442391
]
Ivan Daschinskiy commented on IGNITE-8021:
--
[~dpavlov] I'm currently working on fixing test. I suppose main cause is
stopAllGrids() instead of stopAllGrids(false) in multiJvm() mode. I'm going to
make JIRA ticket in a few moments.
> Destroyed caches can be return to life by restart grid
> --
>
> Key: IGNITE-8021
> URL: https://issues.apache.org/jira/browse/IGNITE-8021
> Project: Ignite
> Issue Type: Bug
>Reporter: Vladislav Pyatkov
>Assignee: Ivan Daschinskiy
>Priority: Major
> Fix For: 2.5
>
> Attachments: 8021-patch-for-patch, DstroedCacheReturnTest.java
>
>
> Cache configuration files stay stored on file system after invoke {{destroy}}
> method.
> By the reason after restart grid all removed caches are start.
>
> Look at the test [^DstroedCacheReturnTest.java]
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-7786) Changing baseline topology on cluster may have error in control.sh utility
[
https://issues.apache.org/jira/browse/IGNITE-7786?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16442007#comment-16442007
]
Ivan Daschinskiy commented on IGNITE-7786:
--
[~dpavlov] Tests seems to be ok for me.
> Changing baseline topology on cluster may have error in control.sh utility
> --
>
> Key: IGNITE-7786
> URL: https://issues.apache.org/jira/browse/IGNITE-7786
> Project: Ignite
> Issue Type: Bug
>Affects Versions: 2.3
>Reporter: Dmitry Sherstobitov
>Assignee: Ivan Daschinskiy
>Priority: Major
>
> Looks like there is hardcoded timeout for waiting result of change baseline
> operation
> In cluster there is following behaviour:
> # Set new baseline topology version
> # Utility starts, but then fails by connection error
> # Cluster successfully activated
> {code:java}
> ...Start node...
> ...Waiting for topology snapshot...
> > control_utility.sh --baseline version 9
> Control utility
> 2017 Copyright(C) Apache Software Foundation
> User: test
>
> Failed to set baseline with specified topology version.
> Connection to cluster failed.
> Error: Failed to perform request (connection failed): /IP
> ...few milliseconds later...
> > control_utility.sh --baseline version 9
> Control utility
> 2017 Copyright(C) Apache Software Foundation
> User: test
>
> Cluster state: active
> Current topology version: 9
> Baseline nodes:
> ConsistentID=node1, STATE=ONLINE
> ConsistentID=node10001, STATE=ONLINE
> ConsistentID=node2, STATE=ONLINE
> ConsistentID=node3, STATE=ONLINE
> ConsistentID=node4, STATE=ONLINE
>
> Number of baseline nodes: 5
> Other nodes not found.{code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-7786) Changing baseline topology on cluster may have error in control.sh utility
[
https://issues.apache.org/jira/browse/IGNITE-7786?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16441040#comment-16441040
]
Ivan Daschinskiy commented on IGNITE-7786:
--
Sure, a little bit later.
> Changing baseline topology on cluster may have error in control.sh utility
> --
>
> Key: IGNITE-7786
> URL: https://issues.apache.org/jira/browse/IGNITE-7786
> Project: Ignite
> Issue Type: Bug
>Affects Versions: 2.3
>Reporter: Dmitry Sherstobitov
>Assignee: Ivan Daschinskiy
>Priority: Major
>
> Looks like there is hardcoded timeout for waiting result of change baseline
> operation
> In cluster there is following behaviour:
> # Set new baseline topology version
> # Utility starts, but then fails by connection error
> # Cluster successfully activated
> {code:java}
> ...Start node...
> ...Waiting for topology snapshot...
> > control_utility.sh --baseline version 9
> Control utility
> 2017 Copyright(C) Apache Software Foundation
> User: test
>
> Failed to set baseline with specified topology version.
> Connection to cluster failed.
> Error: Failed to perform request (connection failed): /IP
> ...few milliseconds later...
> > control_utility.sh --baseline version 9
> Control utility
> 2017 Copyright(C) Apache Software Foundation
> User: test
>
> Cluster state: active
> Current topology version: 9
> Baseline nodes:
> ConsistentID=node1, STATE=ONLINE
> ConsistentID=node10001, STATE=ONLINE
> ConsistentID=node2, STATE=ONLINE
> ConsistentID=node3, STATE=ONLINE
> ConsistentID=node4, STATE=ONLINE
>
> Number of baseline nodes: 5
> Other nodes not found.{code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-7786) Changing baseline topology on cluster may have error in control.sh utility
[
https://issues.apache.org/jira/browse/IGNITE-7786?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16440986#comment-16440986
]
Ivan Daschinskiy commented on IGNITE-7786:
--
I implements a little bit different idea. I use GridClientConfiguration plus I
fixed U.currentTimeMillies() issue thanks to
[~macrergate]. I think a new approach is better.
> Changing baseline topology on cluster may have error in control.sh utility
> --
>
> Key: IGNITE-7786
> URL: https://issues.apache.org/jira/browse/IGNITE-7786
> Project: Ignite
> Issue Type: Bug
>Affects Versions: 2.3
>Reporter: Dmitry Sherstobitov
>Assignee: Ivan Daschinskiy
>Priority: Major
>
> Looks like there is hardcoded timeout for waiting result of change baseline
> operation
> In cluster there is following behaviour:
> # Set new baseline topology version
> # Utility starts, but then fails by connection error
> # Cluster successfully activated
> {code:java}
> ...Start node...
> ...Waiting for topology snapshot...
> > control_utility.sh --baseline version 9
> Control utility
> 2017 Copyright(C) Apache Software Foundation
> User: test
>
> Failed to set baseline with specified topology version.
> Connection to cluster failed.
> Error: Failed to perform request (connection failed): /IP
> ...few milliseconds later...
> > control_utility.sh --baseline version 9
> Control utility
> 2017 Copyright(C) Apache Software Foundation
> User: test
>
> Cluster state: active
> Current topology version: 9
> Baseline nodes:
> ConsistentID=node1, STATE=ONLINE
> ConsistentID=node10001, STATE=ONLINE
> ConsistentID=node2, STATE=ONLINE
> ConsistentID=node3, STATE=ONLINE
> ConsistentID=node4, STATE=ONLINE
>
> Number of baseline nodes: 5
> Other nodes not found.{code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-7786) Changing baseline topology on cluster may have error in control.sh utility
[
https://issues.apache.org/jira/browse/IGNITE-7786?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16440980#comment-16440980
]
Ivan Daschinskiy commented on IGNITE-7786:
--
Yes, to all actions. But user can specify these params by himself using cmd
params.
> Changing baseline topology on cluster may have error in control.sh utility
> --
>
> Key: IGNITE-7786
> URL: https://issues.apache.org/jira/browse/IGNITE-7786
> Project: Ignite
> Issue Type: Bug
>Affects Versions: 2.3
>Reporter: Dmitry Sherstobitov
>Assignee: Ivan Daschinskiy
>Priority: Major
>
> Looks like there is hardcoded timeout for waiting result of change baseline
> operation
> In cluster there is following behaviour:
> # Set new baseline topology version
> # Utility starts, but then fails by connection error
> # Cluster successfully activated
> {code:java}
> ...Start node...
> ...Waiting for topology snapshot...
> > control_utility.sh --baseline version 9
> Control utility
> 2017 Copyright(C) Apache Software Foundation
> User: test
>
> Failed to set baseline with specified topology version.
> Connection to cluster failed.
> Error: Failed to perform request (connection failed): /IP
> ...few milliseconds later...
> > control_utility.sh --baseline version 9
> Control utility
> 2017 Copyright(C) Apache Software Foundation
> User: test
>
> Cluster state: active
> Current topology version: 9
> Baseline nodes:
> ConsistentID=node1, STATE=ONLINE
> ConsistentID=node10001, STATE=ONLINE
> ConsistentID=node2, STATE=ONLINE
> ConsistentID=node3, STATE=ONLINE
> ConsistentID=node4, STATE=ONLINE
>
> Number of baseline nodes: 5
> Other nodes not found.{code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Assigned] (IGNITE-7786) Changing baseline topology on cluster may have error in control.sh utility
[
https://issues.apache.org/jira/browse/IGNITE-7786?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ivan Daschinskiy reassigned IGNITE-7786:
Assignee: Ivan Daschinskiy
> Changing baseline topology on cluster may have error in control.sh utility
> --
>
> Key: IGNITE-7786
> URL: https://issues.apache.org/jira/browse/IGNITE-7786
> Project: Ignite
> Issue Type: Bug
>Affects Versions: 2.3
>Reporter: Dmitry Sherstobitov
>Assignee: Ivan Daschinskiy
>Priority: Major
>
> Looks like there is hardcoded timeout for waiting result of change baseline
> operation
> In cluster there is following behaviour:
> # Set new baseline topology version
> # Utility starts, but then fails by connection error
> # Cluster successfully activated
> {code:java}
> ...Start node...
> ...Waiting for topology snapshot...
> > control_utility.sh --baseline version 9
> Control utility
> 2017 Copyright(C) Apache Software Foundation
> User: test
>
> Failed to set baseline with specified topology version.
> Connection to cluster failed.
> Error: Failed to perform request (connection failed): /IP
> ...few milliseconds later...
> > control_utility.sh --baseline version 9
> Control utility
> 2017 Copyright(C) Apache Software Foundation
> User: test
>
> Cluster state: active
> Current topology version: 9
> Baseline nodes:
> ConsistentID=node1, STATE=ONLINE
> ConsistentID=node10001, STATE=ONLINE
> ConsistentID=node2, STATE=ONLINE
> ConsistentID=node3, STATE=ONLINE
> ConsistentID=node4, STATE=ONLINE
>
> Number of baseline nodes: 5
> Other nodes not found.{code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-7786) Changing baseline topology on cluster may have error in control.sh utility
[
https://issues.apache.org/jira/browse/IGNITE-7786?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16439602#comment-16439602
]
Ivan Daschinskiy commented on IGNITE-7786:
--
Number of retries and timeout between retries are hardcoded in
GridClientAbstractProjection, 3 and 1000ms respectively. This affects therefore
all GridClientCompute invocations, not only control.sh. I suggest to introduce
new System properties: i.e IGNITE_GRID_CLIENT_COMPUTE_RECONNECT_TIMEOUT and
IGNITE_GRID_CLIENT_COMPUTE_NUM_RETRIES.
> Changing baseline topology on cluster may have error in control.sh utility
> --
>
> Key: IGNITE-7786
> URL: https://issues.apache.org/jira/browse/IGNITE-7786
> Project: Ignite
> Issue Type: Bug
>Affects Versions: 2.3
>Reporter: Dmitry Sherstobitov
>Priority: Major
>
> Looks like there is hardcoded timeout for waiting result of change baseline
> operation
> In cluster there is following behaviour:
> # Set new baseline topology version
> # Utility starts, but then fails by connection error
> # Cluster successfully activated
> {code:java}
> ...Start node...
> ...Waiting for topology snapshot...
> > control_utility.sh --baseline version 9
> Control utility
> 2017 Copyright(C) Apache Software Foundation
> User: test
>
> Failed to set baseline with specified topology version.
> Connection to cluster failed.
> Error: Failed to perform request (connection failed): /IP
> ...few milliseconds later...
> > control_utility.sh --baseline version 9
> Control utility
> 2017 Copyright(C) Apache Software Foundation
> User: test
>
> Cluster state: active
> Current topology version: 9
> Baseline nodes:
> ConsistentID=node1, STATE=ONLINE
> ConsistentID=node10001, STATE=ONLINE
> ConsistentID=node2, STATE=ONLINE
> ConsistentID=node3, STATE=ONLINE
> ConsistentID=node4, STATE=ONLINE
>
> Number of baseline nodes: 5
> Other nodes not found.{code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Assigned] (IGNITE-8203) Interrupting task can cause node fail with PersistenceStorageIOException.
[ https://issues.apache.org/jira/browse/IGNITE-8203?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ivan Daschinskiy reassigned IGNITE-8203: Assignee: Ivan Daschinskiy > Interrupting task can cause node fail with PersistenceStorageIOException. > -- > > Key: IGNITE-8203 > URL: https://issues.apache.org/jira/browse/IGNITE-8203 > Project: Ignite > Issue Type: Bug > Components: persistence >Affects Versions: 2.4 >Reporter: Ivan Daschinskiy >Assignee: Ivan Daschinskiy >Priority: Major > Fix For: 2.6 > > Attachments: GridFailNodesOnCanceledTaskTest.java > > > Interrupting task with simple cache operations (i.e. get, put) can cause > PersistenceStorageIOException. Main cause of this failure is lack of proper > handling InterruptedException in FilePageStore.init() etc. This cause a throw > of ClosedByInterruptException by FileChannel.write() and so on. > PersistenceStorageIOException is a critical failure and typically makes a > node to stop. As a workaround, I would suggest to enable AsyncFileIO by > default until the fix was available. > A reproducer is attached. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-8021) Destroyed caches can be return to life by restart grid
[
https://issues.apache.org/jira/browse/IGNITE-8021?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16439154#comment-16439154
]
Ivan Daschinskiy commented on IGNITE-8021:
--
[~ilyak] I suppose I've fixed WAL iterator and now your test completes without
error. Thank you.
[[~EdShangGG] I've also tested your case and it seems now it's ok.
> Destroyed caches can be return to life by restart grid
> --
>
> Key: IGNITE-8021
> URL: https://issues.apache.org/jira/browse/IGNITE-8021
> Project: Ignite
> Issue Type: Bug
>Reporter: Vladislav Pyatkov
>Assignee: Ivan Daschinskiy
>Priority: Major
> Attachments: 8021-patch-for-patch, DstroedCacheReturnTest.java
>
>
> Cache configuration files stay stored on file system after invoke {{destroy}}
> method.
> By the reason after restart grid all removed caches are start.
>
> Look at the test [^DstroedCacheReturnTest.java]
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (IGNITE-8203) Interrupting task can cause node fail with PersistenceStorageIOException.
[ https://issues.apache.org/jira/browse/IGNITE-8203?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ivan Daschinskiy updated IGNITE-8203: - Description: Interrupting task with simple cache operations (i.e. get, put) can cause PersistenceStorageIOException. Main cause of this failure is lack of proper handling InterruptedException in FilePageStore.init() etc. This cause a throw of ClosedByInterruptException by FileChannel.write() and so on. PersistenceStorageIOException is a critical failure and typically makes a node to stop. A reproducer is attached. was: Interrupting task with simple cache operations (i.e. get, put) can cause PersistenceStorageIOException. Main cause of this failure is lack of proper handling InterruptedException in FilePageStore.init() etc. This cause a throw ClosedByInterruptException by FileChannel.write() and so on. PersistenceStorageIOException is a critical failure and typically makes a node to stop. As a workaround, I would suggest to enable AsyncFileIO by default until the fix was available. A reproducer is attached. > Interrupting task can cause node fail with PersistenceStorageIOException. > -- > > Key: IGNITE-8203 > URL: https://issues.apache.org/jira/browse/IGNITE-8203 > Project: Ignite > Issue Type: Bug > Components: persistence >Affects Versions: 2.4 >Reporter: Ivan Daschinskiy >Priority: Major > Fix For: 2.6 > > Attachments: GridFailNodesOnCanceledTaskTest.java > > > Interrupting task with simple cache operations (i.e. get, put) can cause > PersistenceStorageIOException. Main cause of this failure is lack of proper > handling InterruptedException in FilePageStore.init() etc. This cause a throw > of ClosedByInterruptException by FileChannel.write() and so on. > PersistenceStorageIOException is a critical failure and typically makes a > node to stop. > A reproducer is attached. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-8203) Interrupting task can cause node fail with PersistenceStorageIOException.
[ https://issues.apache.org/jira/browse/IGNITE-8203?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ivan Daschinskiy updated IGNITE-8203: - Description: Interrupting task with simple cache operations (i.e. get, put) can cause PersistenceStorageIOException. Main cause of this failure is lack of proper handling InterruptedException in FilePageStore.init() etc. This cause a throw of ClosedByInterruptException by FileChannel.write() and so on. PersistenceStorageIOException is a critical failure and typically makes a node to stop. As a workaround, I would suggest to enable AsyncFileIO by default until the fix was available. A reproducer is attached. was: Interrupting task with simple cache operations (i.e. get, put) can cause PersistenceStorageIOException. Main cause of this failure is lack of proper handling InterruptedException in FilePageStore.init() etc. This cause a throw of ClosedByInterruptException by FileChannel.write() and so on. PersistenceStorageIOException is a critical failure and typically makes a node to stop. A reproducer is attached. > Interrupting task can cause node fail with PersistenceStorageIOException. > -- > > Key: IGNITE-8203 > URL: https://issues.apache.org/jira/browse/IGNITE-8203 > Project: Ignite > Issue Type: Bug > Components: persistence >Affects Versions: 2.4 >Reporter: Ivan Daschinskiy >Priority: Major > Fix For: 2.6 > > Attachments: GridFailNodesOnCanceledTaskTest.java > > > Interrupting task with simple cache operations (i.e. get, put) can cause > PersistenceStorageIOException. Main cause of this failure is lack of proper > handling InterruptedException in FilePageStore.init() etc. This cause a throw > of ClosedByInterruptException by FileChannel.write() and so on. > PersistenceStorageIOException is a critical failure and typically makes a > node to stop. As a workaround, I would suggest to enable AsyncFileIO by > default until the fix was available. > A reproducer is attached. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-8203) Interrupting task can cause node fail with PersistenceStorageIOException.
[ https://issues.apache.org/jira/browse/IGNITE-8203?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ivan Daschinskiy updated IGNITE-8203: - Description: Interrupting task with simple cache operations (i.e. get, put) can cause PersistenceStorageIOException. Main cause of this failure is lack of proper handling InterruptedException in FilePageStore.init() etc. This cause a throw ClosedByInterruptException by FileChannel.write() and so on. PersistenceStorageIOException is a critical failure and typically makes a node to stop. As a workaround, I would suggest to enable AsyncFileIO by default until the fix was available. A reproducer is attached. was: Interrupting task with simple cache operations (i.e. get, put) can cause PersistenceStorageIOException. Main cause of this failure is lack of proper handling InterruptedException in FilePageStore.init() etc. This cause a throw ClosedByInterruptException by FileChannel.write() and so on. PersistenceStorageIOException is a critical failure and typically makes a node to stop. As a workaround, I would suggest to enable AsyncFileIO by default A reproducer is attached. > Interrupting task can cause node fail with PersistenceStorageIOException. > -- > > Key: IGNITE-8203 > URL: https://issues.apache.org/jira/browse/IGNITE-8203 > Project: Ignite > Issue Type: Bug > Components: persistence >Affects Versions: 2.4 >Reporter: Ivan Daschinskiy >Priority: Major > Fix For: 2.6 > > Attachments: GridFailNodesOnCanceledTaskTest.java > > > Interrupting task with simple cache operations (i.e. get, put) can cause > PersistenceStorageIOException. Main cause of this failure is lack of proper > handling InterruptedException in FilePageStore.init() etc. This cause a throw > ClosedByInterruptException by FileChannel.write() and so on. > PersistenceStorageIOException is a critical failure and typically makes a > node to stop. As a workaround, I would suggest to enable AsyncFileIO by > default until the fix was available. > A reproducer is attached. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-8203) Interrupting task can cause node fail with PersistenceStorageIOException.
[ https://issues.apache.org/jira/browse/IGNITE-8203?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ivan Daschinskiy updated IGNITE-8203: - Description: Interrupting task with simple cache operations (i.e. get, put) can cause PersistenceStorageIOException. Main cause of this failure is lack of proper handling InterruptedException in FilePageStore.init() etc. This cause a throw ClosedByInterruptException by FileChannel.write() and so on. PersistenceStorageIOException is a critical failure and typically makes a node to stop. As a workaround, I would suggest to enable AsyncFileIO by default A reproducer is attached. was: Interrupting task with simple cache operations (i.e. get, put) can cause PersistenceStorageIOException. Main cause of this failure is lack of proper handling InterruptedException in FilePageStore.init() etc. This cause a throw ClosedByInterruptException by FileChannel.write() and so on. PersistenceStorageIOException is a critical failure and typically makes a node to stop. A reproducer is attached. > Interrupting task can cause node fail with PersistenceStorageIOException. > -- > > Key: IGNITE-8203 > URL: https://issues.apache.org/jira/browse/IGNITE-8203 > Project: Ignite > Issue Type: Bug > Components: persistence >Affects Versions: 2.4 >Reporter: Ivan Daschinskiy >Priority: Major > Fix For: 2.6 > > Attachments: GridFailNodesOnCanceledTaskTest.java > > > Interrupting task with simple cache operations (i.e. get, put) can cause > PersistenceStorageIOException. Main cause of this failure is lack of proper > handling InterruptedException in FilePageStore.init() etc. This cause a throw > ClosedByInterruptException by FileChannel.write() and so on. > PersistenceStorageIOException is a critical failure and typically makes a > node to stop. As a workaround, I would suggest to enable AsyncFileIO by > default > A reproducer is attached. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-8203) Interrupting task can cause node fail with PersistenceStorageIOException.
Ivan Daschinskiy created IGNITE-8203: Summary: Interrupting task can cause node fail with PersistenceStorageIOException. Key: IGNITE-8203 URL: https://issues.apache.org/jira/browse/IGNITE-8203 Project: Ignite Issue Type: Bug Components: persistence Affects Versions: 2.4 Reporter: Ivan Daschinskiy Fix For: 2.6 Attachments: GridFailNodesOnCanceledTaskTest.java Interrupting task with simple cache operations (i.e. get, put) can cause PersistenceStorageIOException. Main cause of this failure is lack of proper handling InterruptedException in FilePageStore.init() etc. This cause a throw ClosedByInterruptException by FileChannel.write() and so on. PersistenceStorageIOException is a critical failure and typically makes a node to stop. A reproducer is attached. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-7654) Geospatial queries does not work for JDBC/ODBC
[
https://issues.apache.org/jira/browse/IGNITE-7654?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ivan Daschinskiy updated IGNITE-7654:
-
Fix Version/s: (was: 2.5)
> Geospatial queries does not work for JDBC/ODBC
> --
>
> Key: IGNITE-7654
> URL: https://issues.apache.org/jira/browse/IGNITE-7654
> Project: Ignite
> Issue Type: Bug
> Components: jdbc, odbc, sql, thin client
>Affects Versions: 2.3
>Reporter: Mikhail Cherkasov
>Assignee: Ivan Daschinskiy
>Priority: Major
>
> Geospatial queries do not work for JDBC/ODBC.
> I can create a table with GEOMETRY from sqlline, like this:
> {code:java}
> CREATE TABLE GEO_TABLE(GID INTEGER PRIMARY KEY, THE_GEOM GEOMETRY);{code}
> I can add rows:
> {code:java}
> INSERT INTO GEO_TABLE(GID, THE_GEOM) VALUES (2, 'POINT(500 505)');{code}
> but there's no way to select GEOMETRY objects:
> {code:java}
> SELECT THE_GEOM FROM GEO_TABLE;{code}
> sqlline throws the following excpetion:
> {noformat}
> Error: class org.apache.ignite.binary.BinaryObjectException: Custom objects
> are not supported (state=5,code=0)
> java.sql.SQLException: class org.apache.ignite.binary.BinaryObjectException:
> Custom objects are not supported
> at
> org.apache.ignite.internal.jdbc.thin.JdbcThinConnection.sendRequest(JdbcThinConnection.java:671)
> at
> org.apache.ignite.internal.jdbc.thin.JdbcThinStatement.execute0(JdbcThinStatement.java:130)
> at
> org.apache.ignite.internal.jdbc.thin.JdbcThinStatement.execute(JdbcThinStatement.java:299)
> at sqlline.Commands.execute(Commands.java:823)
> at sqlline.Commands.sql(Commands.java:733)
> at sqlline.SqlLine.dispatch(SqlLine.java:795)
> at sqlline.SqlLine.begin(SqlLine.java:668)
> at sqlline.SqlLine.start(SqlLine.java:373)
> at sqlline.SqlLine.main(SqlLine.java:265){noformat}
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (IGNITE-8120) Improve test coverage of rebalance failing
[ https://issues.apache.org/jira/browse/IGNITE-8120?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ivan Daschinskiy updated IGNITE-8120: - Fix Version/s: (was: 2.5) 2.6 > Improve test coverage of rebalance failing > -- > > Key: IGNITE-8120 > URL: https://issues.apache.org/jira/browse/IGNITE-8120 > Project: Ignite > Issue Type: Test > Components: general >Affects Versions: 2.4 >Reporter: Ivan Daschinskiy >Assignee: Ivan Daschinskiy >Priority: Minor > Labels: test > Fix For: 2.6 > > > Need to cover situation, when some archived wal segments, which are not > reserved by IgniteWriteAheadLogManager, are deleted during rebalancing or > were deleted before. However, rebalancing from WAL is broken. When fix > [IGNITE-8116|https://issues.apache.org/jira/browse/IGNITE-8116] is available, > it will be implemented. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-7912) control.sh script should show used WAL-segments
[ https://issues.apache.org/jira/browse/IGNITE-7912?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16428047#comment-16428047 ] Ivan Daschinskiy commented on IGNITE-7912: -- [~agura] Thank you for your review. I suppose I've corrected all issues you've found. > control.sh script should show used WAL-segments > --- > > Key: IGNITE-7912 > URL: https://issues.apache.org/jira/browse/IGNITE-7912 > Project: Ignite > Issue Type: Improvement >Reporter: Sergey Filatov >Assignee: Ivan Daschinskiy >Priority: Minor > > We have to erase wal archive because wal archive can grow large and we must > have safe way to remove unused segments to free disk space. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-8078) Add new metrics for data storage
[
https://issues.apache.org/jira/browse/IGNITE-8078?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16424282#comment-16424282
]
Ivan Daschinskiy commented on IGNITE-8078:
--
[~DmitriyGovorukhin], may be it's better to extend already implemented
TcpDiscoverySpiMBean.getCoordinator()? i.e. this method could return String
formed by U.toString(ClusterNode) instead of UUID.
> Add new metrics for data storage
>
>
> Key: IGNITE-8078
> URL: https://issues.apache.org/jira/browse/IGNITE-8078
> Project: Ignite
> Issue Type: New Feature
>Reporter: Dmitriy Govorukhin
>Assignee: Dmitriy Govorukhin
>Priority: Major
> Labels: iep-6
> Fix For: 2.5
>
>
> 1. Create new MXbean for each index, IndexMxBean
> {code}
> class IndexMxBean{
> /** The number of PUT operations on the index. */
> long getProcessedPuts();
> /** The number of GET operations on the index. */
> long getProcessedGets();
> /** The total index size in bytes. */
> long getIndexSize();
> /** Index name.*/
> String getName();
> }
> {code}
> 2. Add new metrics for data storage and cache group.
> {code}
> class CacheGroupMetricsMXBean{
> /** The total index size in bytes */
> long getIndexesSize();
> /** Total size in bytes for primary key indexes. */
> long getPKIndexesSize();
> /** Total size in bytes for reuse list.*/
> long getReuseListSize();
> /** Total size in bytes. */
> long getTotalSize();
> /** Total size in bytes for pure data.*/
> long getDataSize();
> /** Total size in bytes for data pages.*/
> long getDataPagesSize();
> /** CacheGroup type. PARTITIONED, REPLICATED, LOCAL.*/
> String getType();
> /** Partitions currently assigned to the local node in this cache group. */
> int[] getPartitions();
> }
> {code}
> {code}
> class DataRegionMXBean{
> /** Total size in bytes for indexes. */
> long getIndexesSize();
> /** Total size in bytes for primary key indexes. */
> long getPKIndexesSize();
> /** Total size in bytes. */
> long getTotalSize();
> /** Total size in bytes for pure data.*/
> long getDataSize();
> /** Total size in bytes for data pages.*/
> long getDataPagesSize();
> /** Total used offheap size in bytes. */
> long getOffheapUsedSize();
> /** The number of read pages from last restart. */
> long getPagesRead();
> /** The number of writen pages from last restart. */
> long getPagesWriten();
> /** The number of replaced pages from last restart . */
> long getPagesReplaced();
> /** Total dirty pages for the next checkpoint. */
> long getDirtyPagesForNextCheckpoint();
> }
> {code}
> {code}
> class DataStorageMXbean{
> /** Total size in bytes for indexes. */
> long getIndexesSize();
> /** Total size in bytes for primary key indexes. */
> long getPKIndexesSize();
> /** Total size in bytes for all storages. */
> long getTotalSize();
> /** Total offheap size in bytes. */
> long getOffHeapSize();
> /** Total used offheap size in bytes for all data regions. */
> long getOffheapUsedSize();
> /** Total size in bytes for pure data.*/
> long getDataSize();
> /** The number of read pages from last restart. */
> long getPagesRead();
> /** The number of writen pages from last restart. */
> long getPagesWriten();
> /** The number of replaced pages from last restart. */
> long getPagesReplaced();
> /** Total checkpoint time from last restart. */
> long getCheckpointTotalTime();
> /** Total dirty pages for the next checkpoint. */
> long getDirtyPagesForNextCheckpoint();
> /** Total size in bytes for storage wal files. */
> long getWalTotalSize();
> /** Time of the last WAL segment rollover. */
> long getWalLastSwitchTime();
> }
> {code}
> {code}
> class IgniteMxBean {
> /** Returns string containing Node ID, Consistent ID, Node Order */
> String getCurrentCoordinator();
> }
> {code}
> Depricate CacheMetrics.getRebalancingPartitionsCount(); and move to
> CacheGroupMetricsMXBean.getRebalancingPartitionsCount();
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (IGNITE-8120) Improve test coverage of rebalance failing
[ https://issues.apache.org/jira/browse/IGNITE-8120?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ivan Daschinskiy updated IGNITE-8120: - Description: Need to cover situation, when some archived wal segments, which are not reserved by IgniteWriteAheadLogManager, are deleted during rebalancing or were deleted before. However, rebalancing from WAL is broken. When fix [IGNITE-8116|https://issues.apache.org/jira/browse/IGNITE-8116] is available, it will be implemented. (was: It is important to test safety of deleting unused WAL segments when node supplies rebalancing. However, rebalancing from WAL is broken. When fix [IGNITE-8116|https://issues.apache.org/jira/browse/IGNITE-8116] is available, it will be implemented.) > Improve test coverage of rebalance failing > -- > > Key: IGNITE-8120 > URL: https://issues.apache.org/jira/browse/IGNITE-8120 > Project: Ignite > Issue Type: Test > Components: general >Affects Versions: 2.4 >Reporter: Ivan Daschinskiy >Assignee: Ivan Daschinskiy >Priority: Minor > Labels: test > Fix For: 2.5 > > > Need to cover situation, when some archived wal segments, which are not > reserved by IgniteWriteAheadLogManager, are deleted during rebalancing or > were deleted before. However, rebalancing from WAL is broken. When fix > [IGNITE-8116|https://issues.apache.org/jira/browse/IGNITE-8116] is available, > it will be implemented. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-8120) Improve test coverage of rebalance failing
[ https://issues.apache.org/jira/browse/IGNITE-8120?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ivan Daschinskiy updated IGNITE-8120: - Description: It is important to test safety of deleting unused WAL segments when node supplies rebalancing. However, rebalancing from WAL is broken. When fix [IGNITE-8116|https://issues.apache.org/jira/browse/IGNITE-8116] is available, it will be implemented. (was: It is important to test safety of deleting unused WAL segments when node supplies rebalancing. However, rebalancing from WAL is broken. After fix [IGNITE-8116|http://example.com] ) > Improve test coverage of rebalance failing > -- > > Key: IGNITE-8120 > URL: https://issues.apache.org/jira/browse/IGNITE-8120 > Project: Ignite > Issue Type: Test > Components: general >Affects Versions: 2.4 >Reporter: Ivan Daschinskiy >Assignee: Ivan Daschinskiy >Priority: Minor > Labels: test > Fix For: 2.5 > > > It is important to test safety of deleting unused WAL segments when node > supplies rebalancing. However, rebalancing from WAL is broken. When fix > [IGNITE-8116|https://issues.apache.org/jira/browse/IGNITE-8116] is available, > it will be implemented. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-8120) Improve test coverage of rebalance failing
[ https://issues.apache.org/jira/browse/IGNITE-8120?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ivan Daschinskiy updated IGNITE-8120: - Description: It is important to test safety of deleting unused WAL segments when node supplies rebalancing. However, rebalancing from WAL is broken. After fix [IGNITE-8116|http://example.com] > Improve test coverage of rebalance failing > -- > > Key: IGNITE-8120 > URL: https://issues.apache.org/jira/browse/IGNITE-8120 > Project: Ignite > Issue Type: Test > Components: general >Affects Versions: 2.4 >Reporter: Ivan Daschinskiy >Assignee: Ivan Daschinskiy >Priority: Minor > Labels: test > Fix For: 2.5 > > > It is important to test safety of deleting unused WAL segments when node > supplies rebalancing. However, rebalancing from WAL is broken. After fix > [IGNITE-8116|http://example.com] -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-8120) Improve test coverage of rebalance failing
Ivan Daschinskiy created IGNITE-8120: Summary: Improve test coverage of rebalance failing Key: IGNITE-8120 URL: https://issues.apache.org/jira/browse/IGNITE-8120 Project: Ignite Issue Type: Test Components: general Affects Versions: 2.4 Reporter: Ivan Daschinskiy Assignee: Ivan Daschinskiy Fix For: 2.5 -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Assigned] (IGNITE-8021) Destroyed caches can be return to life by restart grid
[
https://issues.apache.org/jira/browse/IGNITE-8021?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ivan Daschinskiy reassigned IGNITE-8021:
Assignee: Ivan Daschinskiy
> Destroyed caches can be return to life by restart grid
> --
>
> Key: IGNITE-8021
> URL: https://issues.apache.org/jira/browse/IGNITE-8021
> Project: Ignite
> Issue Type: Bug
>Reporter: Vladislav Pyatkov
>Assignee: Ivan Daschinskiy
>Priority: Major
> Attachments: DstroedCacheReturnTest.java
>
>
> Cache configuration files stay stored on file system after invoke {{destroy}}
> method.
> By the reason after restart grid all removed caches are start.
>
> Look at the test [^DstroedCacheReturnTest.java]
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
