Currently it is possible to have Tasks which are queued while the database connection is in the process of being disconnected from the database. As the running Task is being rejected by the onend event it will trigger the next Task. This task is removed from the queue and send to the connection. Resulting in the connection becoming dormant and the started Task hanging. Additionally all queued Tasks are completely discarded when onclose is called. Which makes all the enqueued Tasks hang.
Visual examples
The current behavior:
sequenceDiagram
participant Connection
participant Queue
participant HANA
Connection->>Queue: Task 1
Connection->>Queue: Task 2
Queue->>Connection: run 1
Connection->>HANA: Task 1
HANA-->>Connection: Disconnect
Connection->>Queue: Task 1 (Error)
Queue->>Queue: next
Queue->>Connection: run 2
Connection->>HANA: Task 2
Connection->>Connection: Update Socket status
Alternative solution would be to call run in the next of the queue with setImmediate, but this might come with an performance impact for positive connection scenarios.
sequenceDiagram
participant Connection
participant Queue
participant HANA
Connection->>Queue: Task 1
Connection->>Queue: Task 2
Queue->>Connection: run 1
Connection->>HANA: Task 1
HANA-->>Connection: Disconnect
Connection->>Queue: Task 1 (Error)
Queue->>Queue: next (setImmediate)
Connection->>Connection: Update Socket Status
Queue->>Connection: run 2
Connection->>Queue: Task 2 (Error)
Description
Currently it is possible to have
Task
s which are queued while the database connection is in the process of being disconnected from the database. As the runningTask
is being rejected by theonend
event it will trigger the nextTask
. This task is removed from the queue and send to the connection. Resulting in the connection becoming dormant and the startedTask
hanging. Additionally all queuedTask
s are completely discarded whenonclose
is called. Which makes all the enqueuedTask
s hang.Visual examples
The current behavior:
The behavior of the PR:
Alternative solution would be to call run in the next of the queue with
setImmediate
, but this might come with an performance impact for positive connection scenarios.