Bug #11325
JVM shutdown hooks executed on FWD server, but they belong to the FWD client
100%
Related issues
History
#1 Updated by Constantin Asofiei 4 months ago
- Related to Support #9709: Needed: Basic example of configuring separate client and server added
#2 Updated by Constantin Asofiei 4 months ago
For temp folder, FWD relies on JVM shutdown hooks executed on the FWD servers. Look how p2j.util.Utils.createDirectoryIfNotExist is used.
For FWD client brokers, the file system is not on the same machine. Thus, temp folders need to be managed on the remote side.
We need to also double-check if other file-system resources are managed by FWD server (like log files?).
#3 Updated by Sergey Ivanovskiy 4 months ago
Why should we manage temporarily folders?
#4 Updated by Constantin Asofiei 4 months ago
Sergey Ivanovskiy wrote:
Why should we manage temporarily folders?
Each client in the legacy OE env runs on its own machine, thus has its own temp folder. In FWD, we ensure this by creating sub-folders under the JVM temp folder, using as name a UUID for that FWD client.
Currently, we have some JVM shutdown hooks to delete these temp folders when the FWD server shuts down. We need to ensure that the temp folders are managed by the FWD client, and also we do our best to remove the folder when the FWD client JVM shuts down. So, the problem we need to fix is when the FWd clients runs on a different machine than the FWD server.
#5 Updated by Teodor Gorghe 4 months ago
- Related to Bug #10136: SESSION:TEMP-DIRECTORY missing directory added
#6 Updated by Sergey Ivanovskiy 4 months ago
- Status changed from New to WIP
I can take this task if there are no objections.
#8 Updated by Sergey Ivanovskiy 4 months ago
The code is used by SESSION:TEMP-DIRECTORY. How should this property be retrieved for 4GL?
Our implementation looks like
/**
* Gets the name of the directory where temporary files are stored.
* Corresponds with the SESSION:TEMP-DIRECTORY system handle attribute.
*
* @return Name of temporary directory.
*/
@Override
public String getTempDirectory()
{
return Utils.getOrCreateDefaultFwdTemporaryDirectory();
}
that seems incorrect because read operation from
SESSION:TEMP-DIRECTORY creates new directory.Constantin, is it correct?
#9 Updated by Teodor Gorghe 4 months ago
+ Constantin
#10 Updated by Sergey Ivanovskiy 4 months ago
Thank you, I should check this. Should we always return the client side directory for this session? If it is executed by the server, then it should delegate this task to the client.
#11 Updated by Teodor Gorghe 4 months ago
Sergey, when I have worked on #10136, I have the similar question.
The reason why we should create the directory is that we don't exactly know the directory when starting the application.
We use some kind of structure like {TMP-DIR}/fwd{random digits}, where these random digits are being generated at runtime. {TMP-DIR} must be there.
Why we are using this structure: because we need to isolate the clients.
Of course, 4GL does not create the temp directories.
#12 Updated by Sergey Ivanovskiy 4 months ago
OK, but should we delegate to OSResourceManager.getInstance().getFileSystem().getTempDirectory()?
#13 Updated by Sergey Ivanovskiy 4 months ago
OK. Do not mind. I will fix this part.
#14 Updated by Constantin Asofiei 4 months ago
Sergey, Teodor is correct, we need explicit temp sub-folder for each FWD client.
Also, using FileSystem resource is OK; and please make the changes in 11325a.
#15 Updated by Sergey Ivanovskiy 4 months ago
Committed revision 16495 (11325a) should fix the shutdown hook on exit by providing which the file system is used the server or client file system.
#16 Updated by Sergey Ivanovskiy 4 months ago
- % Done changed from 0 to 100
- Status changed from WIP to Review
Please review 16495 (11325a).
#18 Updated by Constantin Asofiei 3 months ago
- I'm OK with the changes, but please rebase
- we also need to ensure when server-side filesystem is in use, the temp folder gets deleted on context cleanup - see the new
ServerFileSystemDaemon.javain trunk; aContextLocal.cleanupneeds to be used to delete the temp folder.
#19 Updated by Sergey Ivanovskiy about 1 month ago
Constantin, I am sorry for missed your note. Do we need to fallback to OrderedShutdownHooks.registerShutdownHook(1, deleteOnExitHook); in additional to ContextLocal.cleanup on the server side?
#20 Updated by Sergey Ivanovskiy about 1 month ago
- % Done changed from 100 to 90
- Status changed from Review to WIP
#21 Updated by Sergey Ivanovskiy about 1 month ago
- % Done changed from 90 to 100
- Status changed from WIP to Review
Constantin, please review the committed revision 16606(11325a).
#22 Updated by Sergey Ivanovskiy 27 days ago
Constantin Asofiei wrote:
Sergey, review for 11325a rev 16495:
- I'm OK with the changes, but please rebase
- we also need to ensure when server-side filesystem is in use, the temp folder gets deleted on context cleanup - see the new
ServerFileSystemDaemon.javain trunk; aContextLocal.cleanupneeds to be used to delete the temp folder.
Constantin, please review 16616(11325a).
#23 Updated by Sergey Ivanovskiy 25 days ago
I rebased 11325a rev 16625.
#24 Updated by Constantin Asofiei 25 days ago
- Status changed from Review to Internal Test
Sergey Ivanovskiy wrote:
I rebased 11325a rev 16625.
Sergey, good work integrating the server-side filesystem changes. Please do some tests.
#25 Updated by Sergey Ivanovskiy 15 days ago
Rebased 11325a up to rev 16641.
#26 Updated by Sergey Ivanovskiy 15 days ago
During manual testing of large customers applications I observed that on soft logout the web client throws IllegalStateException
The same issue can be reproduced with the current trunk version.
#27 Updated by Sergey Ivanovskiy 15 days ago
Main CHUI regression tests were passed with 2 known failed test cases.
#28 Updated by Sergey Ivanovskiy 14 days ago
CHUI regression tests were passed. Hotel Gui web client in the virtual desktop mode and in the embedded mode has no new regressions.
It seems that this branch can be merged into the trunk.
#29 Updated by Constantin Asofiei 14 days ago
- Status changed from Internal Test to Merge Pending
11325a can be merged now.
#30 Updated by Sergey Ivanovskiy 14 days ago
- Status changed from Merge Pending to Test
Branch 11325a was merged into the trunk as rev 16639 and archived.