FSM Script Task: DataAccessException -> access denied
Author: ADR81SGP
Publication Date: 7/16/2021 12:54
Dear FirstSpirit Community,
we have an issue in an FSM script where the attached error occurs when executing on the server in a project in schedule entries.
Before the isolated-mode migration of the server it worked perfectly fine. No logical code changes happend in between.
The first few lines of the script are executed as I see a log message indicating the same, but after that, I get that error as attached. On what line the error is thrown, I am not sure of.
Have you experienced this kind of error and can give a hint where it may occur?
Are any code changes necessary for isolated-mode except module-isolated.xml and pom.xml?
Java version: 11
FirstSpirit version: 2020-05
I kindly ask for some insights from your end. Thank you!
Tags: fsm, isolated mode, java
-
Author: felix_reinhold - 7/20/2021 7:21
Hi Eric,
code changes are necessary if you've used Methods and classes that are for internal use only. It's hard to help without the script but in this case:
Did you set the "All permissions" checkbox after updating the module? It looks like an exception when accessing the filesystem (which requires this flag).
Best regards
Felix
0 -
Author: ADR81SGP - 7/20/2021 8:13
Hi Felix,
I was afraid you would say something like that.
I checked the "All Permissions" checkbox and it indeed is set. I also use a custom connection in the ScriptTask.
Anyhow, I executed it again now and I get a different error as attached.
0 -
Author: felix_reinhold - 7/20/2021 11:22
Hi Eric,
since the error relates to the berkeley db you could ask the helpdesk for support. Maybe it's just a corrupt section which could be fixed with the repository viewer - but in this case the problem should already occur in legacy mode. I only know this exception if the java security policy isn't set correctly, but that doesn't relate to the isolated mode as well.
I guess the HelpDesk is your best option here.
To quickly check if a specific section is the problem you could add log output to:
com.bosch.firstspirit.settings.replacer.DataProviderMaps.lambda$getDeclaredVariablesMap$1(DataProviderMaps.java:25)
Just log the section and skip the section that is logged when the error occurs
.
Best regards
Felix
0 -
Author: ADR81SGP - 7/21/2021 11:07
Hi Felix,
wow, now I feel like a dope, I did not see that! Let's pick it up from there. The method is as following:
@NotNull static Map<String, DataProvider> getDeclaredVariablesMap(@NotNull List<DataProvider> dataProviders) {
final Map<String, DataProvider> map = new HashMap<>();
dataProviders.parallelStream().forEach(dataProvider -> {
final FormData formData = dataProvider.getFormData();
final List<GomFormElement> gomFormElements = new ArrayList<>();
formData.getForm().forms().forEach(gomFormElements::add);
gomFormElements.forEach(gomFormElement -> map.put(String.valueOf(gomFormElement.getName()), dataProvider));
});
//map.forEach((variableName, dataProvider) -> logDebug("\"" + variableName + "\"", Logger.class));
return map;
}
Could the issue be here in some method call inside the method? By the logs, I would say it is between line 4 and 11.
0 -
Author: felix_reinhold - 7/21/2021 11:47
Hi Eric,
it's this line:
final FormData formData = dataProvider.getFormData();
Before that line you could add a log output (or of course use remote debugging) to get the id of the dataProvider that is creating the error.
Best case: There's just one corrupt page/section that can be fixed via RepositoryViewer.
If not then you seem to have issues with your berkeley db. In both cases you should ask the e-Spirit Helpdesk for support (if you don't have any experience in using the RepositoryViewer).
Best regards
Felix
0 -
Author: ADR81SGP - 7/21/2021 12:09
Hi Felix,
awesome, I looked for the ID of the data provider causing the problem and we just found the issue or rather the source of the issue. In line 5 we try to get the form data of a page where a FS_CATALOG is placed. Then the exception occurs.
What does that tell us though? I know for a fact that I can call getFormData() on any page.
0 -
Author: felix_reinhold - 7/22/2021 10:38
Hi Eric, have you tested, if the issue still persist, if you skip that page?
But nevertheless you should open a helpdesk ticket for that issue.
0 -
Author: ADR81SGP - 7/22/2021 12:55
Hi Felix,
sorry for my rather short answer before. The issue does not persist when removing the FS_CATALOG from the template of that aforementioned issue-causing page. So I need to do some digging why this FS_CATALOG is causing the exception of "cannot load section."
Yeah well, to say the least: the helpdesk told me to come here to the community and address the issue in the first place. They told me: "since this is an issue with an implementation and no product problem I have to forward you to our Professional Service or our community."
Or do you think now it is not an implementation problem any longer?
0 -
Author: felix_reinhold - 7/22/2021 14:48
Hi Eric,
if you keep the FS_CATALOG in the template can you reproduce the error by calling getFormData on the page from Beanshell Console?
I'm still trying to figure out the conneciton between the isolated mode and this change.
I thought that maybe one or more of the embedded contents in the FS_CATALOG are using templates with custom inputcomponents, DataAccessPlugins, Hotspots or stuff like that that can be affected by the isolated mode.
Maybe we should just do a short websession - that might be faster :smileygrin:
You can write me an email to fr@accitio.com to find a timeslot
0 -
Author: ADR81SGP - 7/22/2021 15:18
Hi Felix,
good idea, I tried below. Output in line 3.
print(context.getElement().getFormData());
Output: de.espirit.firstspirit.store.access.DataWrappingFormData@a03f51a
I will send you an email. Thanks!
0 -
Author: ADR81SGP - 7/23/2021 6:58
Hi Felix,
I got some new insights after adding more logging messages to the method:
DEBUG 23.07.2021 07:43:48.550 (org.slf4j.Logger): Reading DataProvider with id 2893587
DEBUG 23.07.2021 07:43:51.619 (org.slf4j.Logger): Got FormData from DataProvider
DEBUG 23.07.2021 07:43:51.619 (org.slf4j.Logger): Got GomFormElements from DataProvider
DEBUG 23.07.2021 07:43:51.619 (org.slf4j.Logger): Added GomFormElements from DataProvider to Map
ERROR 23.07.2021 07:43:51.626{dNR=} (de.espirit.firstspirit.server.scheduler.ScriptTaskExecutor): error during script execution : java.lang.IllegalStateException: java.lang.IllegalStateException: Error loading revision (revisionId=57883) - de.espirit.storage.backend.BackendClosedException: Database error: com.sleepycat7.je.EnvironmentFailureException: (JE 7.5.11) /net/si0vm04828/fs0/wcms/fs/data/projects/project_2893322/repository/bdb7 fetchIN of 0xc9/0x346a5 parent IN=330 IN class="com".sleepycat7.je.tree.IN lastFullLsn=0xd1/0x61e079 lastLoggedLsn=0xd1/0x61e079 parent.getDirty()=false state=0 expires=never java.security.AccessControlException: access denied ("java.io.FilePermission" "/net/si0vm04828/fs0/wcms/fs/data/projects/project_2893322/repository/bdb7/000000c9.jdb" "read") LOG_INTEGRITY: Log information is incorrect, problem is likely persistent.
So practically the lambda expression executes completely for that one DataProvider that when deleting it from the project the exception does not occur anymore. So the lambda executes to the end of the iteration and then we get that exception in line 5.
0 -
Author: ADR81SGP - 7/23/2021 10:16
Hi Felix,
I figured out what the issue is here: as I used a parallelStream() lambda expression when iterating the DataProviders and the pages seem to be co-dependent it might so happen that I access a page from two different forks of the stream at the same time. Hence, we get the access denied exception. :smileysilly:
So I changed now the following
dataProviders.parallelStream().forEach(dataProvider -> { ... });
to
dataProviders.forEach(dataProvider -> { ... });
So much trouble, such a simple cause.
0
Vous devez vous connecter pour laisser un commentaire.
Commentaires
12 commentaires