Central worker recovery should not be triggered because of unacknowledged messages

[cloudslang]

Central worker recovery should not be triggered because of unacknowledged messages

[natabeck]

In case we have un acked messages and we dont have additional worker to assign the messages to - then those flows are supposed to go to PAUSED - NO_WORKER_IN_GROUP status. Once the recovery of the worker is finished the user can resume those flows. The behaviour that is described above is not expected - I think there is some issue with that specific environment.

[meshipeer]

why this is here?

[danfilip]

we could at least improve logging and debug the queue message id's in the log. this way we would know that if the same messages are printed as unassigned, that there is a corruption.

[danfilip]

hi all.

attaching simple and effective change of reading unack messages.
only changed the sql query to join the queues with the states table , so that we only read queues records that have a corresponding record in the states table.

also removed the original subselect with a more efficient group by clause, achieving the same result.

new select looks like this:

final private String QUERY_COUNT_MESSAGES_WITHOUT_ACK_FOR_WORKER_SQL =
        "SELECT COUNT(*) FROM " +
                " ( " +
                "   SELECT COUNT(*) DUMMY " +
                "   FROM  OO_EXECUTION_QUEUES  q " +
                "   INNER JOIN OO_EXECUTION_STATES st " +
                "   ON q.EXEC_STATE_ID = st.ID " +
                "   WHERE " +
                "   q.ASSIGNED_WORKER  = ? " +
                "   GROUP BY q.EXEC_STATE_ID " +
                "   HAVING MAX(q.STATUS) = ? and MAX(q.MSG_VERSION) < ? " +
                " ) SUBSELECT ";

Patch file here:
unack_read_consistent_records.patch.txt