BinaryHandler not working?

[hrstoyanov]

Hello,
I register a TsidHandler into ES:

return EmbeddedStorageFoundation.New()
                .setConfiguration(StorageConfiguration.Builder()
                        .setStorageFileProvider(storageLiveFileProvider)
                        .setChannelCountProvider(StorageChannelCountProvider.New(channelCount))
                        .setBackupSetup(storageBackupSetup)
                        .createConfiguration())
                .onConnectionFoundation(BinaryHandlersJDK8::registerJDK8TypeHandlers)
                .onConnectionFoundation(BinaryHandlersJDK17::registerJDK17TypeHandlers)
                .onConnectionFoundation(f -> f.registerCustomTypeHandler(new TsidHandler())) // THIS ONE!
                .createEmbeddedStorageManager();

TSID (time sorted ids) is an economical and convenient 64-bit replacement for Java 128-bit UUIDs , which I would like ES to store as/convert to long values. However, when I put break points in the handler code below, none of the handler's methods get triggered (except the constructor). Why is ES ignoring my binary TsidHandler - what am I doing wrong?

public class TsidHandler extends AbstractBinaryHandlerCustomValueFixedLength<Tsid, Long> {

    public TsidHandler() {
        super(Tsid.class, defineValueType(long.class));
    }

    private static long instanceState(final Tsid instance)
    {
        return instance.toLong();
    }

    private static long binaryState(final Binary data)
    {
        return data.read_long(0);
    }

    @Override
    public void store(Binary data, Tsid instance, long objectId, PersistenceStoreHandler<Binary> handler) {
        data.storeLong(this.typeId(), objectId, instance.toLong());
    }

    @Override
    public Tsid create(final Binary data, final PersistenceLoadHandler handler) {
        return Tsid.from(data.read_long(0));
    }


    /** actually never called, just to satisfy the interface */
    @Override
    public Long getValidationStateFromInstance(final Tsid instance) {
        return instance.toLong();
    }

    /** actually never called, just to satisfy the interface */
    @Override
    public Long getValidationStateFromBinary(final Binary data) {
        return binaryState(data);
    }

    @Override
    public void validateState(Binary data, Tsid instance, PersistenceLoadHandler handler) {
        long instanceState = instanceState(instance);
        long binaryState   = binaryState(data);
        if(instanceState == binaryState) return;
        throwInconsistentStateException(instance, instanceState, binaryState);
    }

}

[dtmarius]

Put .onConnectionFoundation(f -> f.registerCustomTypeHandler(new TsidHandler())) above the JDK BinaryHandlers and it will work.
I will try to write more details later.

[hrstoyanov]

Thanks @dtmarius ! Yes, it worked! If this is explicitly mentioned in the ES docs, then it is my fault, but otherwise - this is serious omission in the docs that need to be corrected, as the failure is silent and the developer might never detect it...

[hg-ms]

Hello,
This is an unwanted behavior we have to fix. The foundations api should not be order depended.

[dtmarius]

As a user I did not expect it to be order dependent, but maybe it is a feature to avoid conflict with default native custom type handlers, see my findings below, please.

[dtmarius]

@hrstoyanov
I knew the solution to your problem so quickly, because I also recently ran into this problem and didn't find a hint in the documentation or examples, so I had to figure it out by reading the code.
Here is the short version of what I have discovered so far:

Methods that I have found to register a CustomTypeHandler manually:

1. .onConnectionFoundation(cf -> cf.registerCustomTypeHandler(new MyCustomBinaryHandler()))
   • Shown in the documentation, but not in combination with the JDK BinaryHandlers: custom-type-handler.html
   • This method only puts the CustomBinaryHandler to an internal Hashtable in the class Default in PersistenceFoundation.java:
     • code location of the Hashtable variable in PersistenceFoundation.java
     • code location of the put operation in PersistenceFoundation.java
   • When the registry is instantiated, the values of the customTypeHandlers are passed as values:
     code location in BinaryPersistenceFoundation.java
   • if the registry is already instanciated the Hashtable would contain the added CustomTypeHandler, but it does not update the customtypehandler registry. code location to read the values of the Hashtable in PersistenceFoundation.java
2. executor.executeTypeHandlerRegistration((r, c) -> r.registerTypeHandler(new MyCustomTypeHandler()));
   • Used in the register method of the JDK BinaryHandlers
   • If not already instanciated, it instanciates the CustomTypeHandlerRegistry: code location in PersistenceFoundation.java
   • adds the CustomTypeHandler to the liveRegistry
     • 1. code location in PersistenceCustomTypeHandlerRegistry.java
     • 2. code location in PersistenceCustomTypeHandlerRegistry.java
3. .onConnectionFoundation(cf -> cf.getCustomTypeHandlerRegistry().registerTypeHandler(new MyCustomBinaryHandler()))
   • If not already instanciated, it instanciates the CustomTypeHandlerRegistry: code location in PersistenceFoundation.java
   • adds the CustomTypeHandler to the liveRegistry like the JDK BinaryHandlers
   • Should be avoided to not conflict with native default binary handlers, if I understand the comment in the code right: comment location in the code of PersistenceFoundation.java

Conclusion
CustomTypeHandlers registered through the first method only get added during the first instanciation of the customTypeHandlerRegistry.
The JDK BinaryHandlers register method creates an instance of the customTypeHandlerRegistry.
If the JDK BinaryHandlers are registered before the first method, then these CustomTypeHandlers are only put into the internal customTypeHandlers variable but not into the actual registry and this is the reason for the silent error.