[infinispan-dev] Configuration changes proposal for 8.0

[Tristan Tarrant]

Hi all,

this is a list of proposed changes for 8.x that affect configuration and 
default behaviour. We built this list last year, but never acted upon 
it, but now I believe it's time to do these changes. Please 
comment/add/remove as you think is appropriate.

- Make IGNORE_RETURN_VALUES the default
- Drop asymmetric marshalling [1]
- Remove/change some transaction options [2]
- ReplicationQueue - one should not be allowed to specify it as an instance
- ReplicationQueue - enabled should be implicit ⇔ interval > 0 || 
queueSize > 0. Also flushing when queueSize has been reached should 
happen async.
- AsyncStoreConfiguration.shutdownTimeout - 
force-immediate=”false[default]” (destructive)
                    .flushLockTimeout - remove as it is no longer used
- BackupConfigurationBuilder - remove getters and implicitly set 
BackupFailurePolicy
- allow setting failurePolicy by class not by string
- Reconsider usefulness of ClusterLoader
- DataContainer.properties - to be removed
- ExpirationConfiguration.reaperEnabled should be removed and the 
interval value used instead
- HashConfiguration - remove deprecated elements
- L1Configuration to fail if the reaper frequency interval is less or 
equal than 0
- LockingConfigurationBuilder.useLockStriping - remove it & 
writeSkewCheck enabled by default and removed
- SingletonStore - pushStateWhenCoordinator implicit by pushStateTimeout 
-> flushTimeout
- StateTransfer.fetchInMemoryState -> renamed to enabled
- StoreAsBinary - remove “enabled” and reply on storeKey/storeBinary + 
remove deprecation
- remove deprecations from TransactionConfiguration and remove 
use1PcForAutCommitTx
- VersioningConfiguration.enabled should be computed based on the scheme 
and removed
- Version - remove the version fields and populate them through a mvn script
- SerializationConfigurationBuilder - consider removing the version field
- ShutdownConfiguration - to be removed, confirm with an email
- TransportConfiguration.distributedSyncTimeout -> global RPC timeout
- strictPeerToPeer should go as it is deprecated


[1] https://issues.jboss.org/browse/ISPN-2939
[2] https://issues.jboss.org/browse/ISPN-3927
-- 
Tristan Tarrant
Infinispan Lead
JBoss, a division of Red Hat