Project

General

Profile

Bug #11104

MSA appserver configuration causes issues reading agent startup parameters.

Added by Artur Școlnic 6 months ago. Updated 6 months ago.

Status:
Closed
Priority:
High
Target version:
-
Start date:
Due date:
% Done:

100%

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

History

#2 Updated by Artur Școlnic 6 months ago

When using the PASOE configuration, the startup parameters configured via directory in server/standard/runtime/default are read and initialized correctly, but on access with SessionUtils._startupParameters(), the context local StartupParameters object returns another instance with null values.

#3 Updated by Artur Școlnic 6 months ago

  • Status changed from New to WIP
  • Assignee set to Artur Școlnic
  • Priority changed from Normal to High

#4 Updated by Artur Școlnic 6 months ago

  • Status changed from WIP to Review

In ClientCore.initializeInMSAContext the parameters set for a MSA context are overwritten with empty parameters.

StartupParameters sp = new StartupParameters();

// finish initializing the thin client
ThinClient.initializePost(config, is.session, is.context, sp, sp.getInitializationFile());

Getting the already set parameters with SessionUtils._startupParameters() solves the issue.
StartupParameters sp = SessionUtils._startupParameters(); // Already set or create new, if not set.

// finish initializing the thin client
ThinClient.initializePost(config, is.session, is.context, sp, sp.getInitializationFile());

I tested the pasoe application, the testing passed.

Constantin, please review.

#5 Updated by Constantin Asofiei 6 months ago

Please post a stacktrace where LogicalTerminal.init() is called for a PASOE context. The reason: LT.init() is called when the context-local var gets called, and this is fragile: if for some reason in the future it gets called before SessionUtils.setStartupParameters(startupParameters); from MultiSessionAppserver.createSessionStartupTask, then it will break again.

#6 Updated by Artur Școlnic 6 months ago

at com.goldencode.p2j.util.SessionUtils.setStartupParameters(SessionUtils.java:1399)
at com.goldencode.p2j.ui.chui.ThinClient.initializePost(ThinClient.java:4044)
at com.goldencode.p2j.main.ClientCore.initializeInMSAContext(ClientCore.java:478) // sets a new parameters object to the same context
at com.goldencode.p2j.ui.LogicalTerminal.init(LogicalTerminal.java:1707)
at com.goldencode.p2j.security.ContextLocal.initializeValue(ContextLocal.java:733)
at com.goldencode.p2j.security.ContextLocal.getImpl(ContextLocal.java:558)
at com.goldencode.p2j.security.ContextLocal.get(ContextLocal.java:460)
at com.goldencode.p2j.ui.LogicalTerminal.locate(LogicalTerminal.java:12879)
at com.goldencode.p2j.ui.LogicalTerminal.getInstance(LogicalTerminal.java:1689)
at com.goldencode.p2j.util.TransactionManager$ContextContainer.obtain(TransactionManager.java:11698)
at com.goldencode.p2j.util.TransactionManager.pushScope(TransactionManager.java:1705)
at com.goldencode.p2j.util.TransactionManager.pushScope(TransactionManager.java:1568)
at com.goldencode.p2j.util.appserver.CoreAppserver.executeScoped(CoreAppserver.java:1684)
at com.goldencode.p2j.util.appserver.CoreAppserver.setOeRequestInfo(CoreAppserver.java:1732)
at com.goldencode.p2j.util.appserver.MultiSessionAppserverManager.setMsaContext(MultiSessionAppserverManager.java:1842)
at com.goldencode.p2j.util.appserver.MultiSessionAppserver$4.coreRun(MultiSessionAppserver.java:1245) // parameters set here correctly
at com.goldencode.p2j.util.appserver.MultiSessionAppserver$MsaTask.run(MultiSessionAppserver.java:2657)

#7 Updated by Constantin Asofiei 6 months ago

Artur, the change is not complete. This is called without the appserver's context:

StartupParameters.initFromDirectory() line: 280    
StandardServer.initializeStartupParameters(StartupParameters) line: 456    
MultiSessionAppserver.initializeAgent() line: 1057    
MultiSessionAppserver.<init>(MultiSessionAppserverDefinition, Supplier<Collection<MultiSessionClientConnection>>, Consumer<Collection<MultiSessionClientConnection>>) line: 231    
MultiSessionAppserverManager$4.startAppserver(int) line: 676    
MultiSessionAppserverManager$4.call() line: 697    
MultiSessionAppserverManager$4.call() line: 1    

so it will not read the runtime/<account> configurations - only per-server configuration. I think this is done too early.

It should be done in the createSessionStartupTask, the MsaTask.coreRun code.

#8 Updated by Artur Școlnic 6 months ago

The way I see it, the appserver reads the parameters from the directory from server/standard/runtime/default, then when a MSA task is ran on that appserver, the parameters are taken from the appserver, is that not expected?
I am not sure where else can the parameters be placed in directory.

#9 Updated by Artur Școlnic 6 months ago

  • Estimated time set to 2.00

#10 Updated by Artur Școlnic 6 months ago

  • Estimated time deleted (2.00)

#11 Updated by Artur Școlnic 6 months ago

Constantin Asofiei wrote:

Artur, the change is not complete. This is called without the appserver's context:
so it will not read the runtime/<account> configurations - only per-server configuration. I think this is done too early.

I see your point, thank you.
The parameter initialization in initializeAgent is done for the server context, not the appserver specific context, I moved the initialization, the code is in the branch, please review.

#12 Updated by Artur Școlnic 6 months ago

  • % Done changed from 0 to 90
  • reviewer Constantin Asofiei added

#13 Updated by Constantin Asofiei 6 months ago

  • Status changed from Review to Internal Test

I'm OK with the change.

#14 Updated by Artur Școlnic 6 months ago

  • % Done changed from 90 to 100

I tested and the parameters are read correctly from the server and appserver specific config, tested both PASOE and classic.

#15 Updated by Constantin Asofiei 6 months ago

  • Status changed from Internal Test to Merge Pending

Please merge 11104a now.

In the future, please post when the branch is created.

#16 Updated by Artur Școlnic 6 months ago

11104a was merged as trunk/16356 and ported to 10614_main/16226.

#17 Updated by Greg Shah 6 months ago

  • Status changed from Merge Pending to Closed

Also available in: Atom PDF