WIP: 5345: Nonpersistent EJB timers #5371
Conversation
poikilotherm
changed the title
|
|
||
| This job is automatically scheduled to run at 2AM local time every night. If really necessary, it is possible (for an advanced user) to change that time by directly editing the EJB timer application table in the database. | ||
| We also recommend that the following entry in the :fixedwidthplain:`domain.xml`: | ||
| ``<ejb-timer-service timer-datasource="jdbc/VDCNetDS">`` is changed back to ``<ejb-timer-service>`` |
There was a problem hiding this comment.
I remember experimenting with this myself (although it was a while ago). I thought leaving the timer-datasource attribute blank would result in the default data source (in practice that would be the local instance of Derby db) being used to persist the timers... I'm assuming I was wrong.
If leaving it blank results in not persisting the timers at all, let's stick with it going forward.
But should this PR then modify the installer script accordingly too?
There was a problem hiding this comment.
Just to be sure we are talking about the same: this instruction has been included in the docs already. Once this PR is merged, IMHO the described steps are not necessary anymore.
A blank option does not mean "non-persistent" by default, a blank option means any new persistent timers introduced later on will be stored in the default datasource (local H2 or Hazelcast cache in Payara). (You need to explicitly declare timers as "non-persistent".)
Yes, the installer (and other places) should be changed, too. The asadmin commands from setup-glassfish.sh regarding JDBC timers can be pruned. Will put that in a separate commit to have more logical chunks.
|
|
||
| Known Issues | ||
| ------------ | ||
|
|
||
| We've received several reports of an intermittent issue where the application fails to deploy with the error message "EJB Timer Service is not available." Please see the :doc:`/admin/troubleshooting` section of this guide for a workaround. | ||
| Former to Dataverse 4.10, we've received several reports of an intermittent issue where the application fails to deploy |
There was a problem hiding this comment.
"Prior to Dataverse 4.10" probably?
There was a problem hiding this comment.
Maybe this should state 4.11/5.0 now as 4.10 is released.
There was a problem hiding this comment.
@poikilotherm So, if I'm reading this correctly, the scheduled tasks are still run by timers, the same exact way as before (and NOT by @schedule attributes, as the developer timers guide appears to suggest); the only difference is that we no longer bother to persist the timers in the database - correct?
Thank you for making the PR; and specifically for improving the documentation. I've made a couple of minor/nitpicking suggestions in separate comments.
poikilotherm
force-pushed
the
5345-nonpersistent-ejb
branch
from
3e4a849 to
1f58405
Compare
poikilotherm
force-pushed
the
5345-nonpersistent-ejb
branch
from
1f58405 to
a7cc7b8
Compare
This needs some sophisticated refactoring to be ready for unit tests.
* This removes the old timer handling completly. No persistent timers present anymore. * Removes timer handling from the Harvester Client Admin UI backing. * This cannot be unit tested as stated in the Javadocs and accepted by @landreev. * This might need refactoring when problems arise from the simple execution approach used for now. Prior to this commit, harvest clients ran on independent timers and thus on independent threads. Now they are executed sequentially, which might lead to problems when harvests last longer and more clients want to run an hour later.
|
@poikilotherm heads up that this pull request has merge conflicts. |
|
Closing in favor of #7416 |
WORK IN PROGRESS - DO NOT MERGE
Related Issues
Pull Request Checklist