Spring-session: Spring Session Support for Hazelcast 4

[mesutcelik]

Hazelcast 4 has recently been released and it is not currently supported.
related : https://stackoverflow.com/questions/60303477/spring-session-with-hazlecast-4

[fisco-unimatic]

I've forked the repo, upgraded the hazelcast dependencies, and fixed the code so that it compiles, but there's a failing integration test, SessionEventHazelcastIndexedSessionRepositoryTests.updateMaxInactiveIntervalTest. Hz is not firing an entry expired event after we update the time-to-live. (It does if I put breakpoints in, or a thread sleep between updating the ttl on the map and updating the session with the entry processor.)

[eleftherias]

@fisco-unimatic Thanks for looking at this issue.
However, this is schedule for the Spring Session 3.x release because it is a major version upgrade to one of our dependencies.
Since Spring Session 3.x does not have a scheduled release date, I would advise pausing any work on this issue, since it may be a while before it can be merged and any code changes may become stale by then.

[rwinch]

Another option is ensuring that we can work with both versions of Hazelcast.

[mesutcelik]

Spring Sessions 2.4+ can support Hazelcast 4+.
Spring Sessions 2.3 and earlier can still support Hazelcast 3.x.

This can be documented so that everyone can be aware of compatibility requirement.

[rwinch]

We can add support for Hazelcast 4, but we must continue to support Hazelcast 3. Our tests should verify that it continues to work as well.

[vpavic]

Spring Sessions 2.4+ can support Hazelcast 4+.

@mesutcelik Spring Session primarily has to align with Spring Boot in terms of managed dependency versions, and since Spring Boot manages those taking semver into account, it's unlikely that upgrade to Hazelcast 4.x will happen before Spring Boot 3.0

It is unfortunate that Hazelcast opted to do so many breaking changes in 4.0 release without ensuring users have a smooth transition period by keeping the old APIs in deprecated form for some time.

[mesutcelik]

@vpavic Thanks for the feedback.

A major release had to be done at some point. Every product does that but good news is that 3.12 will be actively supported and this support can be considered as deprecation policy. See active branches for 3.x

Hazelcast has also clear Migration Guide for the documentation of breaking changes.

In terms of SpringBoot compatibility, Spring Boot 2.2.x works fine with Hazelcast 4 except Spring Boot Actuator. Micrometer needs to give Hazelcast 4 Support first. Once that is resolved then Hazelcast Dependency can be upgraded to 4.x

[eleftherias]

There is a similar issue in the Spring Boot repository, https://github.com/spring-projects/spring-boot/issues/20856, which the team has tackled by offering best effort support for Hazelcast 4, https://github.com/spring-projects/spring-boot/issues/21169.

This means that if a user decides to override the dependency management and use Hazelcast 4, they will have some functionality, but likely not full support.
For information on why that is the case, see the discussion on https://github.com/spring-projects/spring-boot/issues/20856.

Spring Session could make similar changes in order to offer best effort support for Hazelcast 4, while still maintaining full support for Hazelcast 3.

[snicoll]

@eleftherias we are considering moving to Hazelcast 4 with Spring Boot 2.4. We will keep compatibility with Hazelcast 3.x but a default Spring Boot 2.4 app would bring Hazelcast 4. I am not keen to proceed until we have some visibility on this particular issue.

Based on another comment of yours it looks like this is scheduled. Can you please clarify?

[eleftherias]

Thanks for pointing that out @snicoll. I have corrected the milestone on this issue to 2.4.0-RC1.

[snicoll]

Thanks @eleftherias. Is there an ETA for a snapshot that includes this fix? I'd like to upgrade but I can't until Spring Session has (optional) support for it. Thanks!

[eleftherias]

@snicoll I plan to have a snapshot that includes a fix at the end of next week or the beginning of the following week so that it is ready in time for RC1.

[eleftherias]

Configuring a Hazelcast instance requires Hazelcast 4 specific classes.
For example:

@Bean
static HazelcastInstance hazelcastInstance() {
    Config config = new Config();
    NetworkConfig networkConfig = config.getNetworkConfig();
    networkConfig.setPort(0);
    networkConfig.getJoin().getMulticastConfig().setEnabled(false);
    AttributeConfig attributeConfig = new AttributeConfig()
            .setName(Hazelcast4IndexedSessionRepository.PRINCIPAL_NAME_ATTRIBUTE)
            .setExtractorClassName(Hazelcast4PrincipalNameExtractor.class.getName());
    config.getMapConfig(Hazelcast4IndexedSessionRepository.DEFAULT_SESSION_MAP_NAME)
            .addAttributeConfig(attributeConfig).addIndexConfig(
                    new IndexConfig(IndexType.HASH, Hazelcast4IndexedSessionRepository.PRINCIPAL_NAME_ATTRIBUTE));
    SerializerConfig serializerConfig = new SerializerConfig();
    serializerConfig.setImplementation(new HazelcastSessionSerializer()).setTypeClass(MapSession.class);
    config.getSerializationConfig().addSerializerConfig(serializerConfig);
    return Hazelcast.newHazelcastInstance(config);
}

[eleftherias]

@snicoll The latest snapshot has the optional support for Hazelcast 4.

[snicoll]

@eleftherias thanks for the follow-up. Unfortunately, I can't test the change as the bom currently points to milestone 1 (I've created https://github.com/spring-projects/spring-session/issues/1685).

The changes look rather involved on the Spring Boot side of things. Do I understand that if Spring Session uses Hazelcast 4

1. We need to Modify how the HazelcastInstance is auto-configured. That's certainly something new which we didn't have to do before
2. Users that provide their own HazelcastInstance must make sure to set those settings as well.

[eleftherias]

@snicoll I updated the BOM to use snapshots.

You are right about the changes involved to configure a HazelcastInstance when using Hazelcast 4.

Even aside from the Spring Session changes, the HazelcastInstance is different because of the name and method signature changes in Hazelcast 4. For example MapAttributeConfig renamed to AttributeConfig.