fix(gtw/jobs): ignore notifications if already scheduled

[romansmirnov]

Description

• Ignore incoming notifications if a notification is already scheduled/running for the given job type
• Changes the type from HashMap to ConcurrentHashMap of field LongPollingActivateJobsHandler#jobTypeState because it is accessed by different threads
  • Actor Thread who does reads and updates to the map
  • "Netty Threads" who notifies the gateway when newly jobs are available

Related issues

closes #8267

Definition of Done

Not all items need to be done depending on the issue and the pull request.

Code changes:

• The changes are backwards compatibility with previous versions
• If it fixes a bug then PRs are created to backport the fix to the last two minor versions. You can trigger a backport by assigning labels (e.g. backport stable/0.25) to the PR, in case that fails you need to create backports manually.

Testing:

• There are unit/integration tests that verify all acceptance criterias of the issue
• New tests are written to ensure backwards compatibility with further versions
• The behavior is tested manually
• The change has been verified by a QA run
• The impact of the changes is verified by a benchmark

Documentation:

• The documentation is updated (e.g. BPMN reference, configuration, examples, get-started guides, etc.)
• New content is added to the release announcement

[romansmirnov]

@deepthidevaki, can you please review this PR? In the case, you can't make it this week anymore, then please let me know.

Regarding a unit test to cover that scenario, I tried different approaches to write a working unit test but did not succeed. If you see any option, how to write a test case, therefore, then please let me know. I am happy to receive your ideas.

[deepthidevaki]

LGTM 🚀
I cannot think of a way to test it other than what we already discussed. Since the existing Long polling tests works, we can assume that it did not break the existing behavior. That would be enough.

Before merging this PR:

1. Could you update the commit message to include a small test describing the reasoning behind these changes. Basically what you have added in the PR description.
2. Have you already run a benchmark to ensure that this fixed the issue?

[romansmirnov]

@deepthidevaki,

Thanks for your review.

Could you update the commit message to include a small test describing the reasoning behind these changes. Basically what you have added in the PR description.

Will do!

Have you already run a benchmark to ensure that this fixed the issue?

Yes, I run the benchmark today and last week, it's documented in the issue itself: #8267 (comment)

[deepthidevaki]

👍

[romansmirnov]

bors r+

[ghost]

Build succeeded:

• continuous-integration/jenkins/branch

[github-actions]

Successfully created backport PR #8345 for stable/1.1.

[github-actions]

Successfully created backport PR #8346 for stable/1.2.