OSGi does not always init properly when adding Workflow Actionlets

wezell commented 1 month ago

Parent Issue

No response

Problem Statement

When dotCMS is running with a plugin that provides a workflow action, and dotCMS gets restarted, there is a race condition between OSGi initing and the plugin trying to register the actionlet. If OSGI is fully initied, the actionlet will register. If not, the actionlet will not show up and the plugin needs to be manually re-added to be able to use the actionlet.

Steps to Reproduce

Its hard to reproduce because does not happen all the time.

Basically, add a plugin that provides an actionlet
Add the actionlet to a workflow action with some config
Make sure it works
restart dotCMS
try the action again.

It especially happens if your felix-cache is persisted across restarts.

Acceptance Criteria

make this not happen

dotCMS Version

24.09

Proposed Objective

Quality Assurance

Proposed Priority

Priority 2 - Important

External Links... Slack Conversations, Support Tickets, Figma Designs, etc.

No response

Assumptions & Initiation Needs

No response

Quality Assurance Notes & Workarounds

No response

Sub-Tasks & Estimates

No response

dsilvam commented 3 weeks ago

Failed IQA: Still requires a redeployment of the plugin that includes actionlets for them to get installed/added.

First time:

dotcms-1      | 21:13:43.929  WARN  rules.RulesAPIImpl - Actionlet with name 'CountRulesActionlet' already registered.
dotcms-1      | 21:13:43.930  WARN  rules.RulesAPIImpl - Actionlet with name 'SetSessionAttributeActionlet' already registered.
dotcms-1      | 21:13:43.930  WARN  rules.RulesAPIImpl - Actionlet with name 'SetRequestAttributeActionlet' already registered.
dotcms-1      | 21:13:43.930  WARN  rules.RulesAPIImpl - Actionlet with name 'SetResponseHeaderActionlet' already registered.
dotcms-1      | 21:13:43.930  WARN  rules.RulesAPIImpl - Actionlet with name 'PersonaActionlet' already registered.
dotcms-1      | 21:13:43.930  WARN  rules.RulesAPIImpl - Actionlet with name 'VisitorTagsActionlet' already registered.
dotcms-1      | 21:13:43.930  WARN  rules.RulesAPIImpl - Actionlet with name 'SendRedirectActionlet' already registered.
dotcms-1      | 21:13:43.930  WARN  rules.RulesAPIImpl - Actionlet with name 'StopProcessingActionlet' already registered.
db-1          | 2024-10-22 21:13:52.246 UTC [45] ERROR:  duplicate key value violates unique constraint "shedlock_pkey"
db-1          | 2024-10-22 21:13:52.246 UTC [45] DETAIL:  Key (name)=(osgi_restart_lock) already exists.
db-1          | 2024-10-22 21:13:52.246 UTC [45] STATEMENT:  INSERT INTO shedlock(name, lock_until, locked_at, locked_by) VALUES($1, $2, $3, $4)
dotcms-1      | 21:13:52.251  INFO  framework.OSGIUtil - Starting the osgi reload on folder: /data/shared/felix/upload
dotcms-1      | 21:13:52.251  INFO  framework.OSGIUtil - OSGI - pathname: vision-0.4.1.jar

After reapplying the plugin:

dotcms-1      | Installing bundle com.dotcms.ai.vision / 0.4.1
dotcms-1      | 21:28:41.696  INFO  vision.Activator - Added actionlet: Open AI - Tag Images
dotcms-1      | 21:28:41.700  INFO  vision.Activator - Added actionlet: Open AI - Translate Content
dotcms-1      | Started bundle: file:/data/shared/felix/load/vision-0.4.1.jar

wezell commented 3 weeks ago

Was this in a cluster and you hit the "reinit plugins"? If so, I think that it is another issue and not the original one.

github-actions[bot] commented 1 week ago

PRs:

dsilvam commented 1 day ago

Failed IQA: Still not loading actionlets consistently when the plugin is installed.

wezell commented 1 day ago

I think we are battling two issues. The original PR fixed the issue of an actionlet loading locally. The second issue is with the use of shedlock to reinit osgi in a cluster that prevents multiple nodes from reloading osgi correctly.

We should not be using shedlock here I don't think. I would be interested in the original reasoning for doing so.

dotCMS / core