GitLab

This is the result of a support case where reading a concurrently
deleted relationship lazily over bolt would result in an
IllegalStateException instead of some transient error that could be
retried. Intended behaviour is to use transient error instead. In the
process, other irregularities where found.

This aligns the node case with how it is done for relationships.
Only return empty labels and properties if node was deleted by us
(if status of ReadAndDeleteTransactionConflictException that we now
get from labels() and properties() is transient)
Co-authored-by: Anton Persson <anton.persson@neotechnology.com>

This is the result of a support case where reading a concurrently
deleted relationship lazily over bolt would result in an
IllegalStateException instead of some transient error that could be
retried. Intended behaviour is to use transient error instead. In the
process, other irregularities where found.

The data that we would read lazily in RelationshipProxyWrappingValue
is relationship type and properties. This is done through different
paths.
- writeTo( AnyValueWriter writer ) where both properties and type are
  read
- properties() where properties are read
- type() where type is read

We want to throw ReadAndDeleteTransactionConflictException which is more
descriptive and contains information about if exception is transient
or not, via Status.

Before
- Could throw NotFoundException or IllegalStateException
  both of which is a result of the relationship being deleted,
  either in this transaction or other concurrent transaction.
Now
- Catch those exceptions and throw ReadAndDeleteTransactionConflictException
  with correct status depending on if relationship was deleted by us
  or by other tx.

Before
- Could throw IllegalStateException caused by deleted relationship, by us or other
Now
- Throw ReadAndDeleteTransactionConflictException with correct Status

// In writeTo we can't throw exception if relationship was deleted by
// us. Instead we keep old behaviour of using EMPTY_MAP instead.
Before
- If reading properties would result in NotFoundException we would use
  EMPTY_MAP. This is only the wanted behaviour if relationship was
  deleted by us.
Now
- Only use EMPTY_MAP for properties if relationship was deleted by us
  (if status of ReadAndDeleteTransactionConflictException that we now
  get from properties() is transient)
Co-authored-by: Anton Persson <anton.persson@neotechnology.com>

Add a note to bug report template to clarify duplicates to prevent multiple issues in the same thread and multiple tickets for the same issue.

Attempt to fix flakey ConnectionTrackingIT by fixing NPE in dbms.listConnections procedure

It has been removed on 4.1 branch in exactly the same way,
so in this sense this change is just a delayed back port.

The reason for the removal is that it is a source of instability
of back up (recovery done as part of the back up process)
reported by some customers

When running over bolt we were failing when trying to delete
a path that has been deleted.

This reverts commit 3a59207dc3632cacd0d13197f63c1a511075a380.

This reverts commit 2f449d23ece4a37455c067c419921b5d44a7edbe.

bouncycastle 1.64 -> 1.68

There was this overly optimistic calculation of amount of active CPUs
in DynamicProcessorAssigner where processing steps that had much lower
average processing time than the slowest would be counted with a factor
less than one. This would in some cases lead to an over-assignment
of threads which could lead to OS scheduling problems. This could lead
to a slowdown of the import as a whole.

Also stops unnecessary removing threads from "too fast" steps if
there are still threads that are unassigned, this to make things
a fair amount more stable so that thread counts doesn't jump up and
down a whole lot once they have been initially assigned.
Now instead moves thread from one step to another if bottlenecks
are discovered.

Some issues could potentially generate huge amount of errors filling up the hard drive.
The report is designed to be human-readable, so 1000 (unknown/unhandled) errors should be enough to indicate what is wrong.

Instead of the dynamically growing cache. The static version is
more efficient and the highNodeId is always known when using it.

Squashed 'public/community/cypher-shell/' content from commit 2b24a37dd5d

git-subtree-dir: public/community/cypher-shell
git-subtree-split: 2b24a37dd5da64bd4f478ad6eb44e93cc843a675

Closes and Closes 
Signed-off-by: Valdemar Roxling <valdemar.roxling@neotechnology.com>

After version bump of jetty, SslContextFactory.Server needs to be used instead of SslContextFactory.

This is solely for testing and will allow tests to produce
records that required secondary units at much lower data sizes.

If a record read was aborted early in the high_limit format
it didn't set the offset of the cursor to the end of the record,
which is its contract to do. Instead it just left it where ever
it was. This was fine for most cases, but the storage-level
cursors "scan" operations took advantage of a store access
method which used the record reading to advance the cursor offset
itself instead of calculating it for every read. Forgetting to
set the offset properly would affect the next read(s) in
quite random ways as it would try to start reading the next
record at an arbitrary place in the store, not at the start
of the record and so data it observed would be total garbage.