I have been trying to do serialization using Jackson, to remove boilerplate serialization code and to support widening of types. Is there a good way to interact with catalyst with a standard interface (Reader/Writer/etc.)?

Since Netty supports it out of the box, perhaps something to look at some point.

In order not to hit any GC pauses can you eliminate any new object creation.

When running with Netty transport I noticed exceptions show up in logs that coincide with a client attempting to establish new sessions:
Failed to connect: /192.168.56.104:9977 java.util.concurrent.CompletionException: java.lang.IllegalStateException: unknown message type: class io.atomix.copycat.client.request.ConnectRequest at java.util.concurrent.CompletableFuture.internalComplete(CompletableFuture.java:205) at java.util.concurrent.CompletableFuture$ThenCopy.run(CompletableFuture.java:1333) at java.util.concurrent.CompletableFuture.postComplete(CompletableFuture.java:193) at java.util.concurrent.CompletableFuture.completeExceptionally(CompletableFuture.java:2361) at io.atomix.copycat.client.session.ClientSession.lambda$setupConnection$14(ClientSession.java:540) at io.atomix.copycat.client.session.ClientSession$$Lambda$190/1395622275.accept(Unknown Source) at java.util.concurrent.CompletableFuture$WhenCompleteCompletion.run(CompletableFuture.java:1298) at java.util.concurrent.CompletableFuture.postComplete(CompletableFuture.java:193) at java.util.concurrent.CompletableFuture.completeExceptionally(CompletableFuture.java:2361) at io.atomix.catalyst.transport.NettyConnection.lambda$handleResponseFailure$9(NettyConnection.java:172)
Upon closer inspection it looks like there is a race between handler registration in ServerState when a new connection is established and handler lookup during request handling time in NettyConnection

I expect the fix should be straightforward. Will submit a pull request shortly.

Allow users to specify custom Protocols to handle parsing of requests and responses at the Transport layer. This will allow, for instance, a REST protocol over HTTP.

Add a Transport implementation on Vert.x 3.

Catalyst has a dependency on Netty 4.0.x but Netty is not backward compatible, so the the 4.1.x and 5.0 are not working due to jar conflicts... Is it possible to bundle the Netty classes inside the Catalyst with a relocation of classes (with maven-shade-plugin for example)? Elasticsearch do this trick in order to avoid conflicts with Lucene and Netty, it might make sense here, what do you think?

Examples:
gRPC/grpc-netty 1.0.1 -> Netty 4.1.3.Final
springframework/spring-web -> 4.1.5.Final

I've got an existing application that embeds a Netty server. I'd also like to implement the copycat framework into this program but I think there be an "issue" with your internal implementation of Netty and one others may have already pre-configured. Going over the code the only place I can find this possibly being a problem is with NettyTransport and it using/building its own EventLoopGroup. Can we create another ctor that optionally takes in an EventLoopGroup that would have been pre-built? Is there another perhaps "better" way of going about this aside from implementing my own Transport? I could take on the work here if folks think it's worthwhile.

Create a separate module/dependency that can hydrate configuration objects (POJOs) from JSON / YAML configuration files.

Deserialization of data from untrusted users can represent a security flaw. While Copycat and Atomix clusters should never be exposed to untrusted users, there's nevertheless no good reason to have dynamic class loading and Java serialization enabled. Performance is slow for Java serialization, and dynamic class loading requires serializing class names. These features should be disabled by default in order to encourage more efficient and secure white listing of classes with space-compact serialization IDs.

When synchronised is used in a multi threaded context there will be always 1 thread in which you can perform the task without synchronisation, hence it might be better through put to store the most likely accessed in a variable called safeThread and check this before entering synchronisation block. If it is the safe thread execute without synchronized wrapper otherwise use the wrapper.

All heap buffers you have are byte based. Can you support all the primitive types.

Two of the unit tests fail on Windows because Windows doesn't like it if you try to delete file that is still open. (You can get away with that on *nix.)

I will submit a pull request shortly. Here are the errors:

Running TestSuite
Tests run: 333, Failures: 2, Errors: 0, Skipped: 0, Time elapsed: 5.816 sec <<< FAILURE! - in TestSuite
testDelete(io.atomix.catalyst.buffer.FileBufferTest) Time elapsed: 0.018 sec <<< FAILURE!
java.lang.RuntimeException:
java.nio.file.FileSystemException: target\test-files\46cd32f5-9ced-4f36-b56c-2448732b90e4: The process cannot access the file because it is being used by another process.

at io.atomix.catalyst.buffer.FileBufferTest.testDelete(FileBufferTest.java:72)

Caused by: java.nio.file.FileSystemException:
target\test-files\46cd32f5-9ced-4f36-b56c-2448732b90e4: The process cannot access the file because it is being used by another process.

at io.atomix.catalyst.buffer.FileBufferTest.testDelete(FileBufferTest.java:72)

testDelete(io.atomix.catalyst.buffer.MappedBufferTest) Time elapsed: 0.003 sec <<< FAILURE!
java.lang.RuntimeException:
java.nio.file.FileSystemException: target\test-files\3eab3429-a82b-4b82-945b-3eccfaff4067: The process cannot access the file because it is being used by another process.

at io.atomix.catalyst.buffer.MappedBufferTest.testDelete(MappedBufferTest.java:74)

Caused by: java.nio.file.FileSystemException:
target\test-files\3eab3429-a82b-4b82-945b-3eccfaff4067: The process cannot access the file because it is being used by another process.

at io.atomix.catalyst.buffer.MappedBufferTest.testDelete(MappedBufferTest.java:74)

Is there any support for extension of serializable data structures that preserves compatibility?

Let's say I have a class that looks like this:

class Data implements CatalystSerializable {

  private String data;

  public void writeObject(BufferOutput<?> buffer, Serializer serializer) {
    buffer.writeString(data);
  }

  public void readObject(BufferInput<?> buffer, Serializer serializer) {
    data = buffer.readString();
  }

...and I work with lists of them (e.g. ArrayList<Data>). Now I want to add another field, let's say boolean anotherField.

The problem I ran into is, how to migrate the data to the newer type. First, I wanted to do something like this:

  public void readObject(BufferInput<?> buffer, Serializer serializer) {
    data = buffer.readString();
    anotherField = buffer.hasRemaining() ? buffer.readBoolean() : false;
  }

...to preserve compatibility, but then I found out that Catalyst doesn't guarantee that hasRemaining() works as expected. And indeed, it didn't work when deserializing ArrayList<Data>. hasRemaining() was returning true also for the Data without anotherField, because there were probably another elements from the same array in the buffer. What's worse, it caused ArrayListSerializer to be misaligned (not on the borders of the elements in the list) and when it tried to deserialize another element, it blew up :)

Is there any way for me to find out whether I have the old Data structure (without anotherField) or not, and act accordingly?

I'd expect that the Catalyst could do the work for me and wrap the elements so that I receive just the one I'm trying to deserialize or at least provide me a way to determine whether there are any data left from the current element in the buffer.

Thanks.

When a FileBuffer is opened on a file that's larger than the initial buffer capacity, reads at the capacity limit of the buffer will result in IndexOutOfBoundsExceptions. File-backed buffers are unique in that the backing bytes may exist prior to the buffer being scaled. File buffers should scale on reads until an EOFException is thrown or the maxCapacity is reached.