|
Re: Use ModelJobs to update UI [message #1864821 is a reply to message #1864818] |
Thu, 11 April 2024 08:44 |
|
That code looks quite good to me. What exactly do you mean by "the form doesn't appear as expected"?
Note that the "waitFor()" call blocks the current thread until the form is closed, i.e. from perspective of the scheduler, that job has not been completed yet. If you need to open a form every X seconds no matter if the previous form has been closed, you can simply remove the waitFor() call.
In some cases it can make sense to use normal jobs to schedule the model job. That way, the triggered jobs will complete fast and don't risk overlapping with the next scheduled execution. Something like this:
Jobs.schedule(() -> { // <-- async job (repeating execution)
LOG.info("Job started");
ModelJobs.schedule(() -> { // <-- model job (one time execution)
LOG.info("Form opened");
MyForm form = new MyForm();
form.start();
form.waitFor();
LOG.info("Form closed");
}, ModelJobs.newInput(ClientRunContexts.copyCurrent()));
LOG.info("Job ended");
}, Jobs.newInput()
.withRunContext(ClientRunContexts.copyCurrent())
.withExecutionTrigger(...) // <-- repeating schedule
);
|
|
|
|
|
Re: Use ModelJobs to update UI [message #1865250 is a reply to message #1865067] |
Mon, 29 April 2024 14:22 |
|
Quote:what do you mean "in some cases"?
As a general rule, the ModelJob should be as short-lived as possible, because while it is running, the UI is blocked for the user. Any substantial "work" that doesn't require interaction with the UI model should be run as a normal job.
Quote:
We have problem with model jobs, sometimes they just stop working.
User needs to logout/login.
We cannot find any reference when this is happening.
Do you think ModelJobs inside Jobs would help?
At least add some log output to your job, see my example above. This should give you a hint where it "stops working".
Generally, Jobs don't just stop, but they can fail with an error. As JD suggested, you should check if any exceptions occurred. If your logger has not been misconfigured, you should see them in your logfile. Note that there are some types of errors that are not visible by default (e.g. ThreadInterruptedError). You can either increase the log level so see them or catch them manually with a try-catch. You can also customize the error handler for each job, see the JavaDoc for JobInput.withExceptionHandling(), although this is rarely necessary. If you use the pattern with two nested jobs, you can catch any error from the inner job while resuming the outer job normally.
|
|
|
Powered by
FUDForum. Page generated in 0.02861 seconds