Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Fix #327: Change machine states by scheduler #331

Merged
merged 11 commits into from
Sep 1, 2022

Conversation

banterCZ
Copy link
Member

No description provided.

*/
@Transactional(readOnly = true)
public void changeMachineStatesInBatch() {
try (Stream<IdentityVerificationEntity> stream = identityVerificationService.streamAllIdentityVerificationsToChangeState().parallel()) {
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Do we want to use .parallel()?

final String processId = identityVerification.getProcessId();
final OwnerId ownerId = new OwnerId();
ownerId.setActivationId(identityVerification.getActivationId());
ownerId.setUserId(identityVerification.getUserId());
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

👀 Needed to have the real userId from IdentityVerificationEntity especially for the presence check provider.

@banterCZ banterCZ marked this pull request as ready for review August 31, 2022 11:19
*
* @return identity verifications
*/
@Query("SELECT id FROM IdentityVerificationEntity id WHERE" +
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Maybe we should consider a refactor of existing DocumentsVerificationSyncTask and ClientEvaluationSyncTask tasks and cover all status = IN_PROGRESS here. But I see this would require adding new actions to the machine. So rather postpone.

Additionally some transitions from the ACCEPTED states could be maybe switched automatically by the state machine to the next state.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I tried to limit where clause as much as possible. I may think about ACCEPTED once again.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I recalled, we need to keep them because another jobs such as DocumentsVerificationSyncTask. We may consolidate it in an extra PR/issue.

Copy link
Contributor

@saalistaja saalistaja left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Well done, looks really promising. There is no issue to address.

@@ -123,6 +134,33 @@ public Message<OnboardingEvent> createMessage(OwnerId ownerId, String processId,
.build();
}

/**
*
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Missing javadoc?

" AND id.status = com.wultra.app.enrollmentserver.model.enumeration.IdentityVerificationStatus.ACCEPTED)" +
" OR (id.phase = com.wultra.app.enrollmentserver.model.enumeration.IdentityVerificationPhase.PRESENCE_CHECK" +
" AND id.status = com.wultra.app.enrollmentserver.model.enumeration.IdentityVerificationStatus.IN_PROGRESS)"
)
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What about some sorting of the result verifications? oldest first?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Do we need it? I mean, in that case we should have an index over updated time, right?

/**
*
*/
@Transactional(readOnly = true)
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I am not sure about duration of the transaction here. Maybe we should limit the timeout with some generous value, but I am pretty sure we can expect that the stream will have an end.

ownerId.setUserId(identityVerification.getUserId());
logger.debug("Changing state of machine for process ID: {}", processId);

transactionTemplate.setPropagationBehavior(TransactionDefinition.PROPAGATION_REQUIRES_NEW);
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I would expect using the shedlock to acquire an exclusive right over the state machine here (shedlock name based on processId?)

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

But for sure exclusive streaming of all waiting verifications by one instance and checking is also a way to go.

/**
* Scheduled task to change machine state.
*/
@Scheduled(cron = "${enrollment-server-onboarding.state-machine.changeMachineState.cron:0/1 * * * * *}", zone = "UTC")
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I am aware of only simple cron patterns. Maybe there is some magic which I don't see here.

What's the frequency of this cron, every second? Is there a difference with * * * * * *?
Maybe we can use e.g. */3.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The default value seems to be inconsistent with the value set in properties file.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ok, we may change it to three seconds, but all cron expressions in enrollment using zero, like 0/5, which should be same.

@Transactional(readOnly = true)
public void changeMachineStatesInBatch() {
try (Stream<IdentityVerificationEntity> stream = identityVerificationService.streamAllIdentityVerificationsToChangeState().parallel()) {
stream.forEach(this::changeMachineState);
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It would be nice to add the number of processed identity verifications per batch, probably in debug level.

Copy link
Member

@romanstrobl romanstrobl left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This looks very promising. Let's deploy the new functionality for testing.

@banterCZ banterCZ merged commit bb3fcef into develop Sep 1, 2022
@banterCZ banterCZ deleted the issues/327-change-state-by-shedlock branch September 1, 2022 09:51
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants