[jira] [Created] (IGNITE-11691) IgniteWalSerializerVersionTest fails in master with NoSuchElementException
Alexey Goncharuk created IGNITE-11691: - Summary: IgniteWalSerializerVersionTest fails in master with NoSuchElementException Key: IGNITE-11691 URL: https://issues.apache.org/jira/browse/IGNITE-11691 Project: Ignite Issue Type: Bug Reporter: Alexey Goncharuk https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8=2723006680195182103=%3Cdefault%3E=testDetails The issue is caused by an incorrect test: test iterator should pass only instances of TimeStamp records. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-11690) .NET: Cache iteration hangs with enabled peerAssemblyLoading
Alexandr Shapkin created IGNITE-11690:
-
Summary: .NET: Cache iteration hangs with enabled
peerAssemblyLoading
Key: IGNITE-11690
URL: https://issues.apache.org/jira/browse/IGNITE-11690
Project: Ignite
Issue Type: Bug
Affects Versions: 2.7
Reporter: Alexandr Shapkin
Assignee: Alexandr Shapkin
Solution to reproduce:
[https://www.dropbox.com/s/xsgqhwjyctyg3o3/Example%20solution.rar?dl=0]
Given:
* 2 server .NET nodes with PeerAssembly = enabled
* Simple custom type cache with a few records
{code:java}
ignite.GetOrCreateCache(new CacheConfiguration(Hotel.Cache, new
QueryEntity(typeof(Guid), typeof(Hotel;
{code}
* 1 Client node that spawn computation task and performs a simple iteration
over cache
{code:java}
class HelloAction : IComputeAction
{
[InstanceResource]
private IIgnite _ignite;
public void Invoke()
{
var hotels = _ignite.GetCache("SomeName").ToList()
}
}
{code}
Problem:
One of the server nodes successfully performs the computation, but the other
getting locked inside the
{code:java}
AssemblyRequestResult ComputeApplySafe(ICompute compute, GetAssemblyFunc func,
AssemblyRequest req)
{code}
When I disable PeerAssembly then all is getting back to normal
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (IGNITE-11689) Additional log info about initiator node in case of RingMessageWorker#processNodeFailedMessage.
Stanilovsky Evgeny created IGNITE-11689:
---
Summary: Additional log info about initiator node in case of
RingMessageWorker#processNodeFailedMessage.
Key: IGNITE-11689
URL: https://issues.apache.org/jira/browse/IGNITE-11689
Project: Ignite
Issue Type: Bug
Components: messaging
Reporter: Stanilovsky Evgeny
Assignee: Stanilovsky Evgeny
Need to have opportunity to get
{code:java}
TcpDiscoveryNodeFailedMessage{code}
message initiator node info.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (IGNITE-11688) [TC Bot] Add more configuration options for VISA
Dmitriy Pavlov created IGNITE-11688: --- Summary: [TC Bot] Add more configuration options for VISA Key: IGNITE-11688 URL: https://issues.apache.org/jira/browse/IGNITE-11688 Project: Ignite Issue Type: Task Reporter: Dmitriy Pavlov Assignee: Dmitriy Pavlov - project - default tracked branch -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-11687) Concurrent WAL replay & log may fail with CRC error on read
Alexey Goncharuk created IGNITE-11687:
-
Summary: Concurrent WAL replay & log may fail with CRC error on
read
Key: IGNITE-11687
URL: https://issues.apache.org/jira/browse/IGNITE-11687
Project: Ignite
Issue Type: Bug
Reporter: Alexey Goncharuk
The cause is the way {{end}} is calculated for WAL iterator:
{code}
if (hnd != null)
end = hnd.position();
{code}
{code}
@Override public FileWALPointer position() {
lock.lock();
try {
return new FileWALPointer(getSegmentId(), (int)written, 0);
}
finally {
lock.unlock();
}
}
{code}
Consider a partially written entry. In this case, {{written}} has been already
updated, concurrent WAL replay will attempt to read the incompletely written
record and since {{end}} is not null, iterator will fail with CRC error.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (IGNITE-11686) MVCC: Create separate test for vacuum checks.
Andrew Mashenkov created IGNITE-11686: - Summary: MVCC: Create separate test for vacuum checks. Key: IGNITE-11686 URL: https://issues.apache.org/jira/browse/IGNITE-11686 Project: Ignite Issue Type: Test Components: mvcc Reporter: Andrew Mashenkov Most of tests (inherited from CacheMvccAbstractTest) run vacuum synchronously on afterTest() method and check if vacuum is ok. This hits performance, can cause false negative results and vacuum issues can be hidden if afterTest method will overriden at once. For now we have CacheMvccVacuumTest that just check vacuum workers state, but there is no check if vacuum really cleans all old versions correctly. I'd expect to find it in this class. So, let's mode vacuum verification from afterTest method into CacheMvccVacuumTest as a new separate test. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-11685) Java thin client: Handle multiple async requests in parallel
Aleksey Plekhanov created IGNITE-11685:
--
Summary: Java thin client: Handle multiple async requests in
parallel
Key: IGNITE-11685
URL: https://issues.apache.org/jira/browse/IGNITE-11685
Project: Ignite
Issue Type: Improvement
Components: thin client
Reporter: Aleksey Plekhanov
In the current implementation {{ReliableChannel}} uses an exclusive lock to
send a request and waits for response synchronously. In this implementation,
there are no benefits of using multiple threads. To improve throughput and
latency we can implement async request/response processing on the client side,
since the server side is already async.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[MTCGA]: new failures in builds [3501904] needs to be handled
Hi Igniters, I've detected some new issue on TeamCity to be handled. You are more than welcomed to help. If your changes can lead to this failure(s): We're grateful that you were a volunteer to make the contribution to this project, but things change and you may no longer be able to finalize your contribution. Could you respond to this email and indicate if you wish to continue and fix test failures or step down and some committer may revert you commit. *New stable failure of a flaky test in master IgniteWalSerializerVersionTest.testCheckDifferentSerializerVersionsAndLogTimestamp https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8=2723006680195182103=%3Cdefault%3E=testDetails No changes in the build - Here's a reminder of what contributors were agreed to do https://cwiki.apache.org/confluence/display/IGNITE/How+to+Contribute - Should you have any questions please contact dev@ignite.apache.org Best Regards, Apache Ignite TeamCity Bot https://github.com/apache/ignite-teamcity-bot Notification generated at 09:43:26 05-04-2019
