[infinispan-dev] Configuration changes proposal for 8.0

[Pedro Ruivo]

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)

>
> [1] https://issues.jboss.org/browse/ISPN-2939
> [2] https://issues.jboss.org/browse/ISPN-3927
>