hhblaze/raft.net

Implementation of RAFT distributed consensus algorithm among TCP Peers on .NET / .NETStandard / .NETCore / dotnet

raft.net's Issues

No graceful way to stop a TcpRaftNode

Currently one has to call Dispose() on a TcpRaftNode to make it shut down (ungracefully) resulting in:

21.08.2018 15:39:57> [ERROR] [System.ObjectDisposedException: Cannot access a disposed object. Object name: 'System.Net.Sockets.Socket'. at System.Net.Sockets.Socket.EndAccept(Byte[]& buffer, Int32& bytesTransferred, IAsyncResult asyncResult) at System.Net.Sockets.TcpListener.EndAcceptTcpClient(IAsyncResult asyncResult) at System.Net.Sockets.TcpListener.<>c.<AcceptTcpClientAsync>b__28_1(IAsyncResult asyncResult) at System.Threading.Tasks.TaskFactory1.FromAsyncCoreLogic(IAsyncResult iar, Func2 endFunction, Action1 endAction, Task1 promise, Boolean requiresSynchronization) --- End of stack trace from previous location where exception was thrown --- at Raft.Transport.TcpRaftNode.StartTcpListener()] [] []

Only using in memory entities, still folders are created.

Only using in memory entities, still folders are created.

Well the title says it all, I’m only using in memory entities, but still Raft creates a folder. Judging by the size, Raft does not store anything in it. Most files are 0 bytes, one or two are 72 bytes.

Is there a way to prevent that from happening?

System.ObjectDisposedException: Cannot access a disposed object. during long buring testing

I'm busy doing a burn-in test, fixed the previous memory leak, and now run into occasional errors;

`[ERROR] [System.ObjectDisposedException: Cannot access a disposed object.
   at System.Threading.TimerQueueTimer.Change(UInt32 dueTime, UInt32 period)
   at System.Threading.Timer.Change(Int32 dueTime, Int32 period)
   at System.Timers.Timer.UpdateTimer()
   at System.Timers.Timer.set_Interval(Double value)
   at Raft.TimeMaster.RecalculateTimer()] [Raft.TimeMaster.RecalculateTimer] []`

This occours only once every day on one of the nodes in a 5 node setup. I'm running two days now, and I see it only 3 times now.

IsLeader?

Hi,
I'm just curious if there is a way to detect if an instance is running as a Leader? The TCPRaftNode class does not offer such an info?
And by the way.... thanks for sharing this project!

No consensus with 2 nodes only

Based on my understanding (RAFT consensus), a RAFT cluster of C(luster)S(ize) = 3 should tolerate the loss of 1 node and still be able to elect a leader.

However, with Raft.NET as soon as the cluster of CS = 3 loses one node (CS = 2) there are no commits until CS is brought back to 3. Basically the absolute minimum of online nodes in a cluster must be 3.

Tested in localhost (Windows 10 .Net Core 2.1) as suggested here: doc

Am I missing something here?

remove LogEntry

remove LogEntry？

Some pictures

Leader has memory leak in a 5 node setup

Setup;

• 5 nodes
• a dataset of 10k records (around 100 bytes per record)
• each node changes one item of the records around every 15 seconds

Config used;

""EntityName"":""default"", ""DelayedPersistenceMs"":500, ""DelayedPersistenceIsActive"":false, ""InMemoryEntity"":true, ""InMemoryEntityStartSyncFromLatestEntity"":true, ""VerboseRaft"":false, ""VerboseTransport"":false

After running around 10 hours, with each node making changes to the dataset, this error occours;

[ERROR] [System.OutOfMemoryException: Exception of type 'System.OutOfMemoryException' was thrown. at DBreeze.LianaTrie.LTrie.Add(Byte[]& key, Byte[]& value, Boolean& WasUpdated, Boolean dontUpdateIfExists) at DBreeze.Transactions.Transaction.Insert[TKey,TValue](String tableName, TKey key, TValue value, Byte[]& refToInsertedValue, Boolean& WasUpdated, Boolean dontUpdateIfExists) at DBreeze.Transactions.Transaction.Insert[TKey,TValue](String tableName, TKey key, TValue value) at Raft.StateLog.AddNextEntryToStateLogByLeader() at Raft.RaftNode.ApplyLogEntry() at Raft.RaftNode.AddLogEntry(Byte[] iData)] [Raft.RaftNode.AddLogEntryLeader] []

All nodes were online, and I'm using the 'InMemoryEntityStartSyncFromLatestEntity' option, so it should not save the entire log right?

In the task manager you can see that only the leader node is using up a lot of memory (3000mb+), the other nodes each take around 300-400mb.