Re: CompactFooter for ClientBinaryMarshaller

[Roman Shtykh]

Thank you for the explanation. But here is the problem is not exactly with 
deserialization but with that a user-defined key is being marshalled to a 
binary object with the compact footer set to true, while the key for putting 
has the footer set to false (which is server default). Thus we have a different 
thing for the key when we try to retrieve and getting null.
Therefore, I suppose switching client to server defaults is what has to be 
done. If the user decides to switch to full schema mode, at least he/she will 
be aware of it. And for deserialization, the schema will be retrieved, as you 
explained. What do you think?

-- Roman
On Friday, January 18, 2019, 10:52:11 p.m. GMT+9, Vladimir Ozerov 
 wrote:  
 
 "Compact footer" is optimization which saves a lot of space. Object serialized 
in this form do not have the full information required for deserialization. 
Metadata necessary for deserialization (aka "schema") is located on cluster 
nodes. For this client it could be requested through special command. Pleass 
see ClientOperation.GET_BINARY_TYPE as a starting point.
On Fri, Jan 18, 2019 at 1:32 PM Igor Sapego  wrote:

I'm not sure, that such a change should be done in minor release, maybe in 3.0
Vova, what do you think? It was you, who designed and developed compact footer, 
right?
Best Regards,Igor

On Fri, Jan 18, 2019 at 4:20 AM Roman Shtykh  wrote:

> I believe it has something to do with backward compatibility.That's what I 
> would like to know.If there's no strong reason to set it to false, it should 
> be as Ignite's default -- that's what a user would expect. And if the user 
> changes the configuration at the cluster, he/she will be aware of that and 
> change it at thin client.If we cannot set it to Ignite's default, we can add 
> a log message saying we force it to false.

--
Roman


    On Thursday, January 17, 2019, 7:11:05 p.m. GMT+9, Igor Sapego 
 wrote:  

 First of all, I do not like that thin client is silently returns null. It 
should be fixed.
For the compact footer being set to false by default - I believe it has 
something to do withbackward compatibility.
Best Regards,Igor

On Thu, Jan 17, 2019 at 7:37 AM Roman Shtykh  wrote:

Igniters,
After putting some data with a user-defined key with a thick client, it's 
impossible to retrieve it with a thin 
client.https://issues.apache.org/jira/browse/IGNITE-10960(I was not sure it was 
a bug, so I first reported the issue to the user ml, Mikhail thanks for 
checking and the jira issue)
That happens because for Ignite `compactFooter` is `true` by default, but 
`ClientBinaryMarshaller` forces it to `false` if `BinaryConfiguration` is not 
created explicitly (see ClientBinaryMarshaller#createImpl).
Any reason to force it to false? I would like to align it with Ignite defaults 
(by setting to true).

-- Roman

  

  

Removed ignite field from TcpDiscoveryIpFinderAdapter, breaking change

[Ilya Kasnacheev]

Hello!

I can see that in this commit
https://github.com/apache/ignite/commit/50dd28d28359930e020cf53d366965fc56b7

protected Ignite ignite; were removed from TcpDiscoveryIpFinderAdapter.java


This is part of public API and one which have very good chances to be used
(extended) in code of our users. They will get compilation errors or even
runtime errors against existing compiled code.

I think that this field should be brought back to this class, compatibility
restored. WDYT?

Regards.
-- 
Ilya Kasnacheev

[jira] [Created] (IGNITE-10989) [TC Bot] Finalize refactoring and remove REST data persistent caches

[Dmitriy Pavlov (JIRA)]

Dmitriy Pavlov created IGNITE-10989:
---

 Summary: [TC Bot] Finalize refactoring and remove REST data 
persistent caches
 Key: IGNITE-10989
 URL: https://issues.apache.org/jira/browse/IGNITE-10989
 Project: Ignite
  Issue Type: Task
Reporter: Dmitriy Pavlov
Assignee: Dmitriy Pavlov


TC Bot was migrated to compacted storage of builds, so now it is no reason to 
keep old-fashioned REST request caches for TeamCity data



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Created] (IGNITE-10988) Zookeeper test case testCommunicationFailureResolve_KillRandom frequently fails in GridAbstractTest.waitForTopology

[Oleg Ignatenko (JIRA)]

Oleg Ignatenko created IGNITE-10988:
---

 Summary: Zookeeper test case 
testCommunicationFailureResolve_KillRandom frequently fails in 
GridAbstractTest.waitForTopology
 Key: IGNITE-10988
 URL: https://issues.apache.org/jira/browse/IGNITE-10988
 Project: Ignite
  Issue Type: Bug
Affects Versions: 2.7
Reporter: Oleg Ignatenko


Zookeeper test case testCommunicationFailureResolve_KillRandom frequently fails 
in GridAbstractTest.waitForTopology.

Teamcity test history in master currently shows "Test runs: 625 total / 251 
failures" 
([link|https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8=-3849782382784091413=testDetails).

Need to find out why is that and whether test case can be improved and made 
more reliable.

Typical failure message looks as follows:
{noformat}
[2019-01-18 06:57:23,489][ERROR][main][root] Test failed.
junit.framework.AssertionFailedError
at junit.framework.Assert.fail(Assert.java:55)
at junit.framework.Assert.assertTrue(Assert.java:22)
at junit.framework.Assert.assertTrue(Assert.java:31)
at 
org.apache.ignite.testframework.junits.GridAbstractTest.waitForTopology(GridAbstractTest.java:2294)
at 
org.apache.ignite.spi.discovery.zk.internal.ZookeeperDiscoverySpiTest.waitForTopology(ZookeeperDiscoverySpiTest.java:5103)
at 
org.apache.ignite.spi.discovery.zk.internal.ZookeeperDiscoverySpiTest.testCommunicationFailureResolve_KillRandom(ZookeeperDiscoverySpiTest.java:3145)
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 
org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:47)
at 
org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
at 
org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:44)
at 
org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
at 
org.apache.ignite.testframework.junits.GridAbstractTest$6.run(GridAbstractTest.java:2088)
at java.lang.Thread.run(Thread.java:748){noformat}

Side note per IGNITE-10777 this test case has moved to another class, from 
{{ZookeeperDiscoverySpiTest}} to {{ZookeeperDiscoverySpiTest5}} but that didn't 
change anything: it still fails frequently and failure message is the same, 
with the only difference in the new test class name.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Created] (IGNITE-10987) --skip-zeros flag of idle_verify command should filter out empty partitions regardless of the value of update counter

[Vyacheslav Koptilin (JIRA)]

Vyacheslav Koptilin created IGNITE-10987:


 Summary: --skip-zeros flag of idle_verify command should filter 
out empty partitions regardless of the value of update counter 
 Key: IGNITE-10987
 URL: https://issues.apache.org/jira/browse/IGNITE-10987
 Project: Ignite
  Issue Type: Test
Affects Versions: 2.7
Reporter: Vyacheslav Koptilin
Assignee: Vyacheslav Koptilin
 Fix For: 2.8






--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Created] (IGNITE-10986) SQL: Drop _VER field support

[Vladimir Ozerov (JIRA)]

Vladimir Ozerov created IGNITE-10986:


 Summary: SQL: Drop _VER field support
 Key: IGNITE-10986
 URL: https://issues.apache.org/jira/browse/IGNITE-10986
 Project: Ignite
  Issue Type: Task
  Components: sql
Reporter: Vladimir Ozerov
Assignee: Alexander Lapin
 Fix For: 2.8


{{_VER}} is undocumented hidden field which is never used in practice. But 
profiling shows that it consumes a lot of memory. Let's drop support of this 
field from all {{GridH2SearchRow}} implementations, as well as from internal 
descriptors.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Created] (IGNITE-10985) SQL: create low-overhead implementation of Row for SELECTs

[Vladimir Ozerov (JIRA)]

Vladimir Ozerov created IGNITE-10985:


 Summary: SQL: create low-overhead implementation of Row for SELECTs
 Key: IGNITE-10985
 URL: https://issues.apache.org/jira/browse/IGNITE-10985
 Project: Ignite
  Issue Type: Task
  Components: sql
Reporter: Vladimir Ozerov
Assignee: Alexander Lapin
 Fix For: 2.8


Currently we use {{GridH2KeyValueRowOnheap}} for both update and search 
operations. This leads to *huge* memory overhead during {{SELECT}} execution. 
If you take a closer look on what is inside the row, you will note the 
following:
# It has both serialized and deserialized {{GridCacheVersion}} which is never 
needed
# It has wrapped key and value object
# It has reference to {{CacheDataRow}} which is not needed either
# It has {{valCache}} field which is never used in SELECT

The goal of this ticket is to created optimized version of row which will be 
created during {{SELECT}} operations only. It should contain only minimally 
necessary information:
# Key (unwrapped!)
# Value (unwrapped!)
# Version (unwrapped, we will remove it completely in separate ticket)

It should not contain reference to {{CacheDataRow}}. There is a chance that we 
will need some pieces from it (e.g. cache ID and link for caching purposes), 
but it definitely will be only small subset of the whole 
{{CacheDataRowAdapter}} (or even worse - {{MvccDataRow}}).

Entry point: {{H2Tree.createRowFromLink}} methods. Note that they return 
{{GridH2Row}}, while in their usages only very relaxed version of 
{{GridH2SearchRow}} is needed. So let's start with new implementation of row 
for these methods and then gradually remove all unnecessary stuff from there.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

Re: IGNITE-10978

[Dmitriy Pavlov]

Hi Konstantin,

Thank you for interest in Apache Ignite and welcome to the Apache Ignite
Community.

I've added you to the list of contributors, so now you can assign an issue
to yourself.

Should you have any questions please do not hesitate to contact Ignite
developers here.

Sincerely,
Dmitriy Pavlov

P.S. Let me share with you
Short 'How to start' guide
https://github.com/apache/ignite/blob/master/CONTRIBUTING.md#contributing-to-apache-ignite

and full guide version
https://cwiki.apache.org/confluence/display/IGNITE/How+to+Contribute

пт, 18 янв. 2019 г. в 17:28, Konstantin Bolyandra :

> Hello Ignite Community!
>
> My name is Konstantin. I want to contribute to Apache Ignite and want to
> start with this issue - IGNITE-10978, my JIRA username kbolyandra. Any
> help on this will be appreciated.
>
> Thanks!
>
> --
> Best Regards,
> Konstantin
>
>

IGNITE-10978

[Konstantin Bolyandra]

Hello Ignite Community!

My name is Konstantin. I want to contribute to Apache Ignite and want to 
start with this issue - IGNITE-10978, my JIRA username kbolyandra. Any 
help on this will be appreciated.


Thanks!

--
Best Regards,
Konstantin

[jira] [Created] (IGNITE-10984) Remove IGNITE_DISABLE_TRIGGERING_CACHE_INTERCEPTOR_ON_CONFLICT option

[Sergey Antonov (JIRA)]

Sergey Antonov created IGNITE-10984:
---

 Summary: Remove 
IGNITE_DISABLE_TRIGGERING_CACHE_INTERCEPTOR_ON_CONFLICT option
 Key: IGNITE-10984
 URL: https://issues.apache.org/jira/browse/IGNITE-10984
 Project: Ignite
  Issue Type: Improvement
Reporter: Sergey Antonov
 Fix For: 3.0


We should rework logic and remove 
IGNITE_DISABLE_TRIGGERING_CACHE_INTERCEPTOR_ON_CONFLICT option.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Created] (IGNITE-10983) Check that persistenceEnabled is consistent on all nodes

[Stanislav Lukyanov (JIRA)]

Stanislav Lukyanov created IGNITE-10983:
---

 Summary: Check that persistenceEnabled is consistent on all nodes
 Key: IGNITE-10983
 URL: https://issues.apache.org/jira/browse/IGNITE-10983
 Project: Ignite
  Issue Type: Task
Reporter: Stanislav Lukyanov


Currently it is possible to have a cluster where the same data region is 
persistent on some nodes and not persistent on others. This use case doesn't 
have enough testing, so it's better to deny it for now by adding a check for 
that and not allowing a node with a different persistenceEnabled value to join 
the cluster.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Created] (IGNITE-10982) Kafka Ignite connect module listen to all related cache node events, not only the source cache

[Mahmoud (JIRA)]

Mahmoud created IGNITE-10982:


 Summary: Kafka Ignite connect module listen to all related cache 
node events, not only the source cache
 Key: IGNITE-10982
 URL: https://issues.apache.org/jira/browse/IGNITE-10982
 Project: Ignite
  Issue Type: Bug
  Components: general
Affects Versions: 2.7
Reporter: Mahmoud


Hey All ,

I see in Kafka module , in

IgniteSourceTask.java , we listen to all target cache node events not only the 
source cache event , is it by design like that ? we should only listen to the 
source cache events through continuous query: 
[https://apacheignite.readme.io/docs/continuous-queries]

 

As we current implementation , we catch all caches events the belong to the 
same source cache node , not only the configured source cache name:

 code snippet from : IgniteSourceTask.java
{code:java}
rmtLsnrId = IgniteGrid.getIgnite().events(IgniteGrid.getIgnite().cluster()
.forCacheNodes(cacheName))
.remoteListen(locLsnr, rmtLsnr, evts);{code}



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

Re: CompactFooter for ClientBinaryMarshaller

[Vladimir Ozerov]

"Compact footer" is optimization which saves a lot of space. Object
serialized in this form do not have the full information required for
deserialization. Metadata necessary for deserialization (aka "schema") is
located on cluster nodes. For this client it could be requested through
special command. Pleass see ClientOperation.GET_BINARY_TYPE as a starting
point.

On Fri, Jan 18, 2019 at 1:32 PM Igor Sapego  wrote:

> I'm not sure, that such a change should be done in minor release, maybe in
> 3.0
>
> Vova, what do you think? It was you, who designed and developed compact
> footer, right?
>
> Best Regards,
> Igor
>
>
> On Fri, Jan 18, 2019 at 4:20 AM Roman Shtykh 
> wrote:
>
>> > I believe it has something to do with backward compatibility.That's
>> what I would like to know.If there's no strong reason to set it to false,
>> it should be as Ignite's default -- that's what a user would expect. And if
>> the user changes the configuration at the cluster, he/she will be aware of
>> that and change it at thin client.If we cannot set it to Ignite's default,
>> we can add a log message saying we force it to false.
>>
>> --
>> Roman
>>
>>
>> On Thursday, January 17, 2019, 7:11:05 p.m. GMT+9, Igor Sapego <
>> isap...@apache.org> wrote:
>>
>>  First of all, I do not like that thin client is silently returns null.
>> It should be fixed.
>> For the compact footer being set to false by default - I believe it has
>> something to do withbackward compatibility.
>> Best Regards,
>> Igor
>>
>>
>> On Thu, Jan 17, 2019 at 7:37 AM Roman Shtykh 
>> wrote:
>>
>> Igniters,
>> After putting some data with a user-defined key with a thick client, it's
>> impossible to retrieve it with a thin client.
>> https://issues.apache.org/jira/browse/IGNITE-10960(I was not sure it was
>> a bug, so I first reported the issue to the user ml, Mikhail thanks for
>> checking and the jira issue)
>> That happens because for Ignite `compactFooter` is `true` by default, but
>> `ClientBinaryMarshaller` forces it to `false` if `BinaryConfiguration` is
>> not created explicitly (see ClientBinaryMarshaller#createImpl).
>> Any reason to force it to false? I would like to align it with Ignite
>> defaults (by setting to true).
>>
>> -- Roman
>>
>>
>
>

[jira] [Created] (IGNITE-10981) CPP: Heap corruption when running C++ tests in Debug mode

[Igor Sapego (JIRA)]

Igor Sapego created IGNITE-10981:


 Summary: CPP: Heap corruption when running C++ tests in Debug mode
 Key: IGNITE-10981
 URL: https://issues.apache.org/jira/browse/IGNITE-10981
 Project: Ignite
  Issue Type: Bug
  Components: platforms
Affects Versions: 2.7
Reporter: Igor Sapego
Assignee: Igor Sapego
 Fix For: 2.8


Currently, heap corruption is detected, when any C++ test is run in Debug mode. 
Need to find out the root cause and fix the issue.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Created] (IGNITE-10980) CPP: Create TC suite for Windows 64 Debug mode

[Igor Sapego (JIRA)]

Igor Sapego created IGNITE-10980:


 Summary: CPP: Create TC suite for Windows 64 Debug mode
 Key: IGNITE-10980
 URL: https://issues.apache.org/jira/browse/IGNITE-10980
 Project: Ignite
  Issue Type: Task
  Components: platforms
Affects Versions: 2.7
Reporter: Igor Sapego
 Fix For: 2.8


Currently, there is a [Platform C++ (Windows 
x64)|https://ci.ignite.apache.org/viewType.html?buildTypeId=IgniteTests24Java8_PlatformCWindowsX64=buildTypeStatusDiv_IgniteTests24Java8=__all_branches__]
 suite, which builds and runs tests in Release mode. It's OK, as we need to 
test Release mode in the first place, as this is the mode, in which user uses 
Ignite C++. But we also need to run tests in Debug mode, as in debug additional 
errors (such as heap corruption and memory leaks) can be detected.

So it is proposed to rename "Platform C++ (Windows x64)" test suite to 
"Platform C++ (Windows x64 Release)" and add another suite "Platform C++ 
(Windows x64 Debug)", which will build and run tests in Debug mode.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Created] (IGNITE-10979) Add documentation for control.sh idle_verify --check-crc

[Sergey Antonov (JIRA)]

Sergey Antonov created IGNITE-10979:
---

 Summary: Add documentation for control.sh idle_verify --check-crc
 Key: IGNITE-10979
 URL: https://issues.apache.org/jira/browse/IGNITE-10979
 Project: Ignite
  Issue Type: New Feature
  Components: documentation
Reporter: Sergey Antonov
Assignee: Artem Budnikov
 Fix For: 2.8


We should document new option --check-crc in control.sh idle_verify command.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Created] (IGNITE-10978) Remove unused tests marked with unclear todo

[Dmitriy Pavlov (JIRA)]

Dmitriy Pavlov created IGNITE-10978:
---

 Summary: Remove unused tests marked with unclear todo
 Key: IGNITE-10978
 URL: https://issues.apache.org/jira/browse/IGNITE-10978
 Project: Ignite
  Issue Type: Task
Reporter: Dmitriy Pavlov
Assignee: Dmitriy Pavlov



{noformat}
// TODO GG-11141.
//
GridTestUtils.addTestIfNeeded(suite,GridCacheOnCopyFlagTxPartitionedSelfTest.class,
 ignoredTests);
//
GridTestUtils.addTestIfNeeded(suite,GridCacheOnCopyFlagReplicatedSelfTest.class,
 ignoredTests);
//
GridTestUtils.addTestIfNeeded(suite,GridCacheOnCopyFlagLocalSelfTest.class, 
ignoredTests);
//
GridTestUtils.addTestIfNeeded(suite,GridCacheOnCopyFlagAtomicSelfTest.class, 
ignoredTests);
{noformat}
Test classes not used, so there is no reason to keep it



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Created] (IGNITE-10977) Document unsupported clean() call for MVCC caches

[Sergey Kozlov (JIRA)]

Sergey Kozlov created IGNITE-10977:
--

 Summary: Document unsupported clean() call for MVCC caches
 Key: IGNITE-10977
 URL: https://issues.apache.org/jira/browse/IGNITE-10977
 Project: Ignite
  Issue Type: Task
  Components: documentation
Affects Versions: 2.7
Reporter: Sergey Kozlov
 Fix For: 2.8


Now MVCC caches don't support {{cache.clean()}} by design. So let's document it 
as a known limitations (I suppose we should have such page on readme.io)



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Created] (IGNITE-10976) MVCC: Sql API methods should throws proper TransactionExceptions in case of tx failure.

[Andrew Mashenkov (JIRA)]

Andrew Mashenkov created IGNITE-10976:
-

 Summary: MVCC: Sql API methods should throws proper 
TransactionExceptions in case of tx failure.
 Key: IGNITE-10976
 URL: https://issues.apache.org/jira/browse/IGNITE-10976
 Project: Ignite
  Issue Type: Bug
  Components: mvcc, sql
Reporter: Andrew Mashenkov
 Fix For: 2.8


For now Sql API can throws SqlException (without any actual Tx failure cause) 
or TransactionException wrapped into CacheException.

Also, I've found we convert unchecked exceptions into checked ones and then 
back without any obvious reason.

Let's make TransactionException thows properly and add it to Sql Api contract.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Created] (IGNITE-10975) when ssl not correct configurate make cu error more undestandable

[ARomantsov (JIRA)]

ARomantsov created IGNITE-10975:
---

 Summary: when ssl not correct configurate make cu error more 
undestandable
 Key: IGNITE-10975
 URL: https://issues.apache.org/jira/browse/IGNITE-10975
 Project: Ignite
  Issue Type: Bug
Reporter: ARomantsov


Now CU return
Connection to cluster failed.
Error: Latest topology update failed 

this error also appear when you try to connect on unexist cluster , at that 
point gain it with bad ssl that add little bit confusion



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

Re: CompactFooter for ClientBinaryMarshaller

[Igor Sapego]

I'm not sure, that such a change should be done in minor release, maybe in
3.0

Vova, what do you think? It was you, who designed and developed compact
footer, right?

Best Regards,
Igor


On Fri, Jan 18, 2019 at 4:20 AM Roman Shtykh 
wrote:

> > I believe it has something to do with backward compatibility.That's what
> I would like to know.If there's no strong reason to set it to false, it
> should be as Ignite's default -- that's what a user would expect. And if
> the user changes the configuration at the cluster, he/she will be aware of
> that and change it at thin client.If we cannot set it to Ignite's default,
> we can add a log message saying we force it to false.
>
> --
> Roman
>
>
> On Thursday, January 17, 2019, 7:11:05 p.m. GMT+9, Igor Sapego <
> isap...@apache.org> wrote:
>
>  First of all, I do not like that thin client is silently returns null. It
> should be fixed.
> For the compact footer being set to false by default - I believe it has
> something to do withbackward compatibility.
> Best Regards,
> Igor
>
>
> On Thu, Jan 17, 2019 at 7:37 AM Roman Shtykh 
> wrote:
>
> Igniters,
> After putting some data with a user-defined key with a thick client, it's
> impossible to retrieve it with a thin client.
> https://issues.apache.org/jira/browse/IGNITE-10960(I was not sure it was
> a bug, so I first reported the issue to the user ml, Mikhail thanks for
> checking and the jira issue)
> That happens because for Ignite `compactFooter` is `true` by default, but
> `ClientBinaryMarshaller` forces it to `false` if `BinaryConfiguration` is
> not created explicitly (see ClientBinaryMarshaller#createImpl).
> Any reason to force it to false? I would like to align it with Ignite
> defaults (by setting to true).
>
> -- Roman
>
>

[jira] [Created] (IGNITE-10974) Grid may hangs if an exception is thrown from PageMemoryImpl.beforeReleaseWrite()

[Dmitriy Govorukhin (JIRA)]

Dmitriy Govorukhin created IGNITE-10974:
---

 Summary: Grid may hangs if an exception is thrown from 
PageMemoryImpl.beforeReleaseWrite()
 Key: IGNITE-10974
 URL: https://issues.apache.org/jira/browse/IGNITE-10974
 Project: Ignite
  Issue Type: Bug
Reporter: Dmitriy Govorukhin
Assignee: Dmitriy Govorukhin


 

 

{code}

[2019-01-17 14:35:15,953][WARN ][main][root] Thread dump at 2019/01/17 14:35:15 
UTC
[17:35:15]W: [org.apache.ignite:ignite-core] Thread 
[name="sys-#857%failure.IoomFailureHandlerTest0%", id=931, state=TIMED_WAITING, 
blockCnt=0, waitCnt=1]
[17:35:15]W: [org.apache.ignite:ignite-core] Lock 
[object=java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject@4339baec,
 ownerName=null, ownerId=-1]
[17:35:15]W: [org.apache.ignite:ignite-core] at sun.misc.Unsafe.park(Native 
Method)
[17:35:15]W: [org.apache.ignite:ignite-core] at 
java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:215)
[17:35:15]W: [org.apache.ignite:ignite-core] at 
java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.awaitNanos(AbstractQueuedSynchronizer.java:2078)
[17:35:15]W: [org.apache.ignite:ignite-core] at 
java.util.concurrent.LinkedBlockingQueue.poll(LinkedBlockingQueue.java:467)
[17:35:15]W: [org.apache.ignite:ignite-core] at 
java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1073)
[17:35:15]W: [org.apache.ignite:ignite-core] at 
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1134)
[17:35:15]W: [org.apache.ignite:ignite-core] at 
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
[17:35:15]W: [org.apache.ignite:ignite-core] at 
java.lang.Thread.run(Thread.java:748)
[17:35:15]W: [org.apache.ignite:ignite-core] 
[17:35:15]W: [org.apache.ignite:ignite-core] Thread 
[name="sys-#856%failure.IoomFailureHandlerTest0%", id=930, state=TIMED_WAITING, 
blockCnt=0, waitCnt=1]
[17:35:15]W: [org.apache.ignite:ignite-core] Lock 
[object=java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject@4339baec,
 ownerName=null, ownerId=-1]
[17:35:15]W: [org.apache.ignite:ignite-core] at sun.misc.Unsafe.park(Native 
Method)
[17:35:15]W: [org.apache.ignite:ignite-core] at 
java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:215)
[17:35:15]W: [org.apache.ignite:ignite-core] at 
java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.awaitNanos(AbstractQueuedSynchronizer.java:2078)
[17:35:15]W: [org.apache.ignite:ignite-core] at 
java.util.concurrent.LinkedBlockingQueue.poll(LinkedBlockingQueue.java:467)
[17:35:15]W: [org.apache.ignite:ignite-core] at 
java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1073)
[17:35:15]W: [org.apache.ignite:ignite-core] at 
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1134)
[17:35:15]W: [org.apache.ignite:ignite-core] at 
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
[17:35:15]W: [org.apache.ignite:ignite-core] at 
java.lang.Thread.run(Thread.java:748)
[17:35:15]W: [org.apache.ignite:ignite-core] 
[17:35:15]W: [org.apache.ignite:ignite-core] Thread 
[name="sys-#855%failure.IoomFailureHandlerTest0%", id=929, state=TIMED_WAITING, 
blockCnt=0, waitCnt=1]
[17:35:15]W: [org.apache.ignite:ignite-core] Lock 
[object=java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject@4339baec,
 ownerName=null, ownerId=-1]
[17:35:15]W: [org.apache.ignite:ignite-core] at sun.misc.Unsafe.park(Native 
Method)
[17:35:15]W: [org.apache.ignite:ignite-core] at 
java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:215)
[17:35:15]W: [org.apache.ignite:ignite-core] at 
java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.awaitNanos(AbstractQueuedSynchronizer.java:2078)
[17:35:15]W: [org.apache.ignite:ignite-core] at 
java.util.concurrent.LinkedBlockingQueue.poll(LinkedBlockingQueue.java:467)
[17:35:15]W: [org.apache.ignite:ignite-core] at 
java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1073)
[17:35:15]W: [org.apache.ignite:ignite-core] at 
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1134)
[17:35:15]W: [org.apache.ignite:ignite-core] at 
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
[17:35:15]W: [org.apache.ignite:ignite-core] at 
java.lang.Thread.run(Thread.java:748)
[17:35:15]W: [org.apache.ignite:ignite-core] 
[17:35:15]W: [org.apache.ignite:ignite-core] Thread 
[name="sys-#854%failure.IoomFailureHandlerTest0%", id=928, state=TIMED_WAITING, 
blockCnt=0, waitCnt=1]
[17:35:15]W: [org.apache.ignite:ignite-core] Lock 
[object=java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject@4339baec,
 ownerName=null, ownerId=-1]
[17:35:15]W: [org.apache.ignite:ignite-core] at sun.misc.Unsafe.park(Native 
Method)
[17:35:15]W: 

[jira] [Created] (IGNITE-10973) Migrate example module tests from Junit 3 to 4

[Ivan Fedotov (JIRA)]

Ivan Fedotov created IGNITE-10973:
-

 Summary: Migrate example module tests from Junit 3 to 4
 Key: IGNITE-10973
 URL: https://issues.apache.org/jira/browse/IGNITE-10973
 Project: Ignite
  Issue Type: Sub-task
Reporter: Ivan Fedotov
Assignee: Ivan Fedotov


For more information refer parent task for more details.
Migrate from Junit 4 to 5 in the example module.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)