…r related config flag "waitForInitialStateTransferToComplete"
…duce RPCs on the server
…instead of the view id. This change is required after introducing NBST.
…value is not yet locally available because state transfer is not yet completed for the key
* Add BaseDistStateTransferConsistencyTest and BaseReplStateTransferConsistencyTest (with subclasses for optimistic and pessimistic locking) to test ISPN-2362 and ISPN-2502 * Add a new flag, Flag.PUT_FOR_STATE_TRANSFER to be use on put commands done by state transfer * LocalQueryInterceptor does not index modifications done by state transfer * Add a isFromStateTransfer flag to LocalTransaction that is set to true only for transactions done by state transfer * BaseRpcInterceptor and BaseBackupInterceptor do not send the command remotely if the transaction is flagged as created by state transfer * Add support in StateConsumer to keep track of keys updated by user code during state transfer: isKeyUpdated/addUpdatedKey/stopRecordingUpdatedKeys. Recording starts when rebalance begins and will end when rebalance ends or when a ClearCommand is executed. * The put command generated by state transfer in StateConsumerImpl is now transactional if the cache is transactional. We no longer use SKIP_LOCKING. This fixes ISPN-2502. * EntryWrappingInterceptor.commitEntryIfNeeded() notifies StateConsumerImpl of any user-updated keys. It also checks if the update is caused by state transfer and the key was previously updated by the user and does not allow the update if so. This ensures no user generated modifications are overwritten or undone by state transfer. * If the update is caused by state transfer, VersionedEntryWrappingInterceptor does not perform a write skew check and does not increment the version before executing prepare and commits the entry into DataContainer using the supplied version as is. We need to bypass incrementation in order to ensure the version is identical to the one on source node of the state transfer. Not doing so will cause subsequent user generated updates to fail due to write skew. Bypassing write skew checks in state transfer does not impact consistency because the state transfer PUT has lower priority than normal user-generated updates and is always rolled back if a user modification is committed before the state transfer PUT attempts to commit. * ReplaceCommand.toString() should also contain the key.
Add configuration option for StateTransferManagerImpl.waitForInitialStateTransferToComplete; default is 'true' to maintain pre-existing behaviour.
* Use HBase test utilities to create a cluster designed to run on unit tests with minimal resources. * Get rid of embedded server helper class. * Use thread locals to create master nodes in different ports * HBase mbean instance already exist WARN message still thrown, but this is a bug in HBase's code which is not naming MBeans correctly. It doesn't affect testsuite completion though.
* Disable Cassandra and HBase modules whose testsuites consume far too many resources. They should be able to work within same JVM as the build to keep resource consumption reasonable. * Scala compiler memory has been increased and in 64 bit environments it uses compressed OOPs. * Switch lucene demo testsuite so that it never forks. * Definte transport protocol at root properties, otherwise when using plattform specific build options (32 bit vs 64 bit), the property is resolved too late and results in test failures.
…erface to allow the use of delegating caches (used by JDG)
- refactored the distribution interceptor into NonTxDistributionInterceptor, L1NonTxInterceptor, TxDistributionInterceptor, L1NonTxInterceptor and BaseDistributionInterceptor - added support for concurrent writes for non-transactional distributed caches: NonTxConcurrentDistributionInterceptor - updated the xml parser in order to support concurrent writes for distributed caches configuration
the root cause of the failure
* This is done by checking that the cache component registry is in RUNNING state, at which point the cache marshaller must be started.
…so happens to break the build
* Fixed by making sure that evicting an entry as a result of exciding the given max size is done within the internal hash map segment lock, and make sure activations happen within this lock too. * This way, concurrent passivation/activation operations will be lined in such way that removing from store (activation) won't happen at the same time as removing entries from memory without providing guarantees that the entry remains in memory. * Added a unit to replicate this entry loss. * Activation interceptor still needed to handle environments where eviction happens manually, via cache.evict() calls.
after JGroups view update When one cache didn't need a topology update (e.g. because it had already processed a LEAVE command), none of the caches following it were updated. I replaced MergeAfterCoordinatorLeaveTest with ClusterTopologyManagerTest, which tests more scenarios (including the one in this bug).
* Also switch Scala maven plugin compile to using more memory efficient options in 64 bit machines.