Project

General

Profile

Bug #11325

JVM shutdown hooks executed on FWD server, but they belong to the FWD client

Added by Constantin Asofiei 4 months ago. Updated 14 days ago.

Status:
Test
Priority:
Normal
Target version:
-
Start date:
Due date:
% Done:

100%

billable:
No
vendor_id:
GCD
case_num:
version_reported:
version_resolved:
production:
No
env_name:
topics:

Related issues

Related to Documentation - Support #9709: Needed: Basic example of configuring separate client and server WIP
Related to Runtime Infrastructure - Bug #10136: SESSION:TEMP-DIRECTORY missing directory Test

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.

#7 Updated by Greg Shah 4 months ago

  • Assignee set to Sergey Ivanovskiy

#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).

#17 Updated by Greg Shah 4 months ago

  • reviewer Constantin Asofiei added

#18 Updated by Constantin Asofiei 3 months ago

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.java in trunk; a ContextLocal.cleanup needs 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.java in trunk; a ContextLocal.cleanup needs 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.

Also available in: Atom PDF