* ENT-1967: Enable byteman library
* ENT-1967: Add an integration test to experiment with Byteman.
This needs to be running with: `-Dexperimental.test.enable`
As in: `gradlew -Dexperimental.test.enable integrationTest`
* ENT-1967: Modify Node driver to allow for optional instrumentation and use it in the integration test
* ENT-1967: Rely on port allocation
* ENT-1967: Install the rule that works
* ENT-1967: Trying to introduce counter rule (doesn't work)
* ENT-1967: Install rules that make correct use of countdown and also improve debug logging for Byteman
* ENT-1967: Add assertion to validate that exception is indeed thrown as per rules installed.
* ENT-1967: Less logging and more assertions
* ENT-1967: Replace `fun` with `val`
* ENT-1967: Un-break DriverDSL public API.
* ENT-1967: Minor change
* ENT-1967: Remove Byteman settings from NodeParameters and hide them inside InternalDriverDSL.
* ENT-1967: Change the way how Jars resolved and use `Try` construct.
* CORDA-1743: Remove `isDebug = true` from Node driver to speed-up integration tests execution.
* CORDA-1743: Undo removal of "isDebug = true" from the test that specifically checks for this condition.
* CORDA-1743: Address input from @shamsasari
The problem manifests itself in IntelliJ when full rebuilt is performed with Gradle delegation.
In this case IntelliJ executes the following tasks:
`:testing:qa:behave:tools:rpc-proxy:classes`, `:testing:qa:behave:tools:rpc-proxy:testClasses`, `:testing:qa:behave:tools:rpc-proxy:smokeTestClasses` and `:testing:qa:behave:tools:rpc-proxy:rpcProxyClasses`
Without the change when `rpcProxyClasses` task executed - the build fails.
The problem is likely to be caused by the fact that this is a multi-sourceSets project.
* ENT-2014 Deletes of NodeInfo can fail to propagate leading to infinite retries
ENT-1880 Move identity key generation to network registration process
(cherry picked from commit c3ac203)
* ENT-1953 enterprise tuning config
* Keep flowThreadPoolSize at 1 for integration tests as some expect certain ordering it seems.
* Log thread count for SMM
* [CORDA-1634] Destroy child processes when parent exits.
* Add comment.
* Register Shutdownhook for processes regardless of whether the Driver was initialized with
* Add comment.
* Revert "Add comment."
This reverts commit a5e78c379f.
* Add comment.
* Add shutdown hook in ShutdownManager.registerProcessShutdown.
* Initialize the ShutdownManager with a shutdown hook to ensure that is called.
* Add comment.
As reported in [CORDA-1609](https://r3-cev.atlassian.net/browse/CORDA-1609),
`CordaRPCClientConfiguration.default` is not accessible from Java since
`default` is a reserved keyword.
As part of the refactor made in #2831, `CordaRPCClientConfiguration` went
from being a data class to an interface with a backing implementation of
type `CordaRPCClientConfigurationImpl`.
This resulted in Java users having to rewrite code that was on the form:
```java
final CordaRPCClient client = new CordaRPCClient(
nodeAddress, CordaRPCClientConfiguration.DEFAULT
);
```
to something like this:
```java
final CordaRPCClient client = new CordaRPCClient(
nodeAddress, CordaRPCClientConfiguration.Companion.default()
);
```
However, this does not work. The user would get a compilation error because
`default` is a reserved keyword in Java.
Since `CordaRPCClientConfiguration` has been made an interface, there is no
easy way of introducing a static final field on the interface from Kotlin.
Consequently, I've changed this back to using a `class` with a static field
named `DEFAULT` instead of the static method `default()`.
It should be noted that `default()` / `DEFAULT` is currently only used
internally to pass in default values in `CordaRPCClient.kt` and
`CordaRPCClientUtils.kt`. That said, it is exposed as part of our API
surface and consequently shouldn't be broken.
The latter means that in the above example, the user would actually not
have to provide the parameter at all:
```java
final CordaRPCClient client = new CordaRPCClient(nodeAddress);
```
As can be seen from the definition of `CordaRPCClient`:
```kotlin
class CordaRPCClient private constructor(...) {
@JvmOverloads
constructor(
hostAndPort: NetworkHostAndPort,
configuration: CordaRPCClientConfiguration = CordaRPCClientConfiguration.DEFAULT
) : this(hostAndPort, configuration, null)
```
The mentioned [refactor](7a077e76f0 (diff-0948c125db93a22263eb81eaf3161c17R65))
did not make it into the 3.1 release, so from an API-stability perspective,
this change can be applied without affecting our commitment to a
backwards compatible API..
* Altering column for SQL Server requires dropping index in which it is a part of and the recreating it
(to avoid Liquibase error: The index 'xxx' is dependent on column 'yyy')
* Remove duplicated addNotNullConstraint causing error on Oracle dbs.
* filter by contract state in _trackBy
* write tests to check that _trackBy is filtering the states correct and tidy up filtering functions
* remove un needed function
* add change log message for filtering unrelated ContractStates from trackBy
* CORDA-1494: Remove isTimed check from flow hospital when handling timeout exceptions - the timeout might expire just after the TimeFlow has finished and the staff member would throw an exception.
Increase the default flow timeout value in mock network so retries don't happen – this has cause test flakiness.
It will re-run automatically from last checkpoint on node restart, allowing the opportunity to resolve the issue, something required when dealing with contract constraint failures.
* Remove all notion of message level retry.
* Introduce randomness into de-duplication IDs based on the session rather than the flow, in support of idempotent flows.
* CORDA-1494: Re-enable notarisation retries in the new state machine manager.
The original message-based retry approach does not work well with the new
flow state machine due to the way sessions are handled. We decided to move
the retry logic to flow-level: introduce RetryableFlow that won't have
checkpoints persisted and will be restarted after a configurable timeout
if it does not complete in time.
The RetryableFlow functionality will be internal for now, as it's mainly
tailored for the notary client flow, and there are many subtle ways it can
fail when used with arbitrary flows.
* Revert back logging of tests (#3305)
* ENT-2023 Minimise code diff between OS and ENT for enterprise change since code diff during merge resulted in a bad merge relating to rpcThreadPoolSize. (#3306)
