[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)
[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-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-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-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-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-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&testNameId=2723006680195182103&branch=%3Cdefault%3E&tab=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)