Re: [infinispan-dev] Configuration changes proposal for 8.0
Hi,
comments inline
Pedro
On 05/13/2015 05:42 PM, Tristan Tarrant wrote:
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
hmmm, not sure about it. it only makes sense for put(k,v) and
remove(k,v) since all other write operations are conditional (i.e. need
the previous value and no optimization can be made)
- 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.
Can we remove the ReplicationQueue? First, it does not have any benefit
(JGroups already bundles the message and the Network can do it too) and
second, it is not more efficient (when the message is delivered, we
process the commands sequentially. So, if the first command blocks, the
other commands are not processed until it finished). Third, it is
complex if you have commands with multiple delivers orders (no order,
FIFO, total)
- 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
didn't get this one ^
- DataContainer.properties - to be removed
so, we will not allow any custom implementation to be configured? or I
miss something?
- 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
write skew check should be moved to Transactions. It is the only place
in which it makes sense
- 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
another suggestion:
- Transaction, remove the transaction_protocol and add TOTAL as an
option for locking_mode
*or*
- Transaction, remove the transaction_protocol
- Locking, add locking mode with LOCK and TOTAL_ORDER options (since
I'll probably implement total order based non transactional caches)