FWD » Core Development » Base Language

Progress allows to set the SESSION:DATE-FORMAT from command-line using the Date Format (-d) option.

Does FWD support setting session date format from command line?

If not, is it hard to implement this?

I am asking this because the current implementation of SESSION:DATE-FORMAT setter is incomplete: the call does not change the existing format instances.

I need to run 4gl test examples with the given date format.
The only way I know how to do this is to set the format unisg SESSION:DATE-FORMAT in the calling procedure, so I must have at least two 4gl files even for a simple test instead of one.

In FWD, the command line options that can be specified in OE are handled using our com.goldencode.p2j.main.StartupParameters facility (see also the supporting code in com.goldencode.p2j.startup.parameters). The StartupParameter class itself defines which of the command line options are currently supported. This implementation accepts both BootstrapConfig values and directory configuration as inputs to define these parameters for a session. BootstrapConfig values can be specified in an .xml file or they can be pass as overrides on the ClientDriver command line (see Bootstrap Configuration).

Currently the -d option is not yet supported, but it is not hard to add.

I've created the 9398a branch for fixing this.

Greg Shah wrote:

Code Review Task Branch 9398a Revision 15628

The changes look good.

Although they are relatively low risk, please make sure they are tested with batch and appserver clients (as well as web GUI).

I've already tested the change with GUI (some of my GUI tests depend on this, and this was the primary goal to fix this).
What is the best way to test with batch and appserver?

Galya and/or Constantin can help with how to use the Testcases project to test appserver.

Batch mode is already reasonably well documented in Batch Processes. You may be able to use an already configured process from a customer project to test. Roger can help with that.

Greg Shah wrote:

Galya and/or Constantin can help with how to use the Testcases project to test appserver.

In testcases directory.xml.template has the appserver configs, that's everything `appserver`. Follow Prerequisites to Running Testcases and link your branch 9398a. Then install the spawner with ./install_spawner.sh. Convert the list of appserver tests (put all file names in file-cvt-list.txt) with ant convert.list jar deploy.prepare. The tricky part is that I don't know what is considered a complete test suite for appserver that passes successfully. Marian is migrating some tests to the new format. Lists like file-cvt-list.txt.rest_and_appserver are not working out of the box, missing some files. Also there are some SOAP UI test suites, that are not completely passing successfully. In some of the above suites there are SOAP tests that need additional configuration to run. All in all I can't help much with deciding what needs to be run. In any case, whatever the test suite, you'll have to cross check the result with trunk and not expect all tests to pass.

Help needed.

Galya B wrote:

I have problem running application server with testcases.

Below is what I've done:

First, a made sure I can run testcases normally. I managed to configure directory.xml for PostgreSQL, convert some ordinary tests, run the server and unit tests. All went smooth.

In testcases directory.xml.template has the appserver configs, that's everything `appserver`.

Next, I have enabled all things in directory.xml, which are related to appserver and/or app_server

.. and link your branch 9398a.

I linked to the latest trunk, which should presumably work.

Then install the spawner with ./install_spawner.sh.

Done

Convert the list of appserver tests (put all file names in file-cvt-list.txt) with ant convert.list jar deploy.prepare.

Converted with no problem.

I have problem with spawning application server:

25/01/13 23:55:32.692+0300 |  SEVERE | com.goldencode.p2j.main.ClientSpawner | ThreadName:Launcher for process 'appserver_process'. [00000000:standard], Session:00000000, ThreadId:00000005, User:standard | The spawn process failed with 149 error. Please see spawner logs.

and the log shows:

Jan 13 23:55:32 gcddev spawn[2250179]: Error:-107 method:CallStaticObjectMethod(command) (No such file or directory)

The problem happens in spawn.c:

   jobjectArray command = (*env)->CallStaticObjectMethod(env, (jclass) cls, (jmethodID) mid,
                                                    port, host, alias, uuid, misc);

   if (command == NULL)
   {
      (*jvm)->DestroyJavaVM(jvm);
      ...      

I added a line to spawn.c to log the values passed to CallStaticObjectMethod, and it shows:

mid -1165229760 port 3333 alias standard host localhost uuid 2ee8f982-53ef-4fed-b4f3-c71573375b0e cmisc net:socket:nio=true.

I gather this calls the NativeSecureConnection:command method, but I do not know how can I debug the spawn process in Java debugger.

No such file or directory probably alludes to workingDir. Make sure to replace all placeholders in directory. To debug the spawn command, you need the spawner logger to ALL in directory:

        <node class="container" name="logging">
          <node class="container" name="loggers">
            <node class="string" name="spawner">
              <node-attribute name="value" value="ALL"/>
            </node>
          </node>
        </node>

Galya B wrote:
Thank you, Galya.

No such file or directory probably alludes to workingDir. Make sure to replace all placeholders in directory.

The directory template is fully processed.
The No such file or directory error code is used unconditionally when the call from spawn.c to Java returns NULL, so I suspect there can be other reasons this call failed, for example, the forked spawn process was not able to connect to server.

To debug the spawn command, you need the spawner logger to ALL in directory:
[...]

Done. Now I see additional log record, which is not very helpful:

25/01/14 10:40:01.447+0300 |    INFO | Spawner-1 | ThreadName:Spawner-1-Logger | Spawn process started with pid 2309064.

Investigating further...

When the spawner logger to ALL you should be getting a record like this, showing the whole command used for spawning new processes:

25/01/14 13:33:26.319+0200 |  FINEST | Spawner-1 | PID:0, ThreadId:00000000 | [ThreadName:main] result = [gbb, "", /home/gbb/Code/testcases1/deploy/client, java, -Djava.awt.headless=true, -Djava.library.path=/home/gbb/Code/testcases1/deploy/lib/, -classpath, /home/gbb/Code/testcases1/deploy/lib/p2j.jar, com.goldencode.p2j.main.ClientDriver, net:server:host=localhost, net:socket:nio=true, net:ssl:trackSeqNo=false, net:connection:secure=true, net:server:secure_port=3333, client:mode:batch=true, client:driver:background=true, client:cmd-line-option:numlogfiles=2, client:cmd-line-option:logthreshold=500000, server:spawner:uuid=f3bc0b97-d264-4dad-9538-6696e4b4ef9d]

I managed to find the current problem source.

The spawner process the working directory argument passed to it from server, and makes it relative to the target OS user home directory.
Meanwhile the file prepare_dir_postgres.json defines this parameter as "../client", which has most probably no sense.
My problem was fixed by making the working directory parameter be an absolute path, and now I see an application server conversation thread on the server.

Probably, this can be considered a bug in prepare_dir_postgres.json, considering all other JSON files in the project define this parameter as "/opt/testcases/client".

Help needed.

Now that I have application server running, I wonder how can I run something on it. Are there any documentation links for that subject?

Vladimir Tsichevski wrote:

Help needed.

Now that I have application server running, I wonder how can I run something on it. Are there any documentation links for that subject?

There could be better ways to run the tests, but what I do is to start a batch client that connects to the appserver and runs an external procedure:

The proc running on the batch client is configured in the client.xml with <cmd-line-option startup-procedure="dir/batch.p"/>:

def var h as handle.

create server h.
h:connect("-S 21500 -H localhost -sessionModel Session-Free -DirectConnect").

run dir/proc.p on h.

h:disconnect().
delete object h.

The port 21500 should be in directory.xml app_services/app_server/ports, localhost is app_services/app_server/p2j_host.

If you want to run multiple procedures at the same time you can have a proc like appsrv/runall.p and it will be called from the above code. All dependencies should be converted as explained earlier.

Greg Shah wrote:

Although they are relatively low risk, please make sure they are tested with batch and appserver clients (as well as web GUI).

At least, I've managed to configure and run testcases in application server mode, and build test code.
Currently the SESSION:DATE-FORMAT set with client:cmd-line-option:date-format option, is set on the client, but is not set in the application server procedure, called by this client.

What is the correct way to propagate this value to application server?

The value can't be propagated from the client to the appserver agent during the call itself. It should be set in the cfgOverrides in the appserver agent configuration (in the directory).

Greg Shah wrote:

The value can't be propagated from the client to the appserver agent during the call itself. It should be set in the cfgOverrides in the appserver agent configuration (in the directory).

I thought the goal was to let different client to the application server to make the remote calls using its own date format. Otherwise, the the clients will have to deal with situation, in which local and remove date formats will be different. I suppose, this can cause problems.

Note, setting SESSION:DATE-FORMAT on the client also does not affect the date format on the application server agent site.

I checked that date format can be successfully set in application server by using the cfgOverrides:

              <node class="string" name="cfgOverrides">
                <node-attribute name="value" value="client:driver:background=true client:cmd-line-option:date-format=mdy"/>
              </node>

Vladimir Tsichevski wrote:

Greg Shah wrote:

The value can't be propagated from the client to the appserver agent during the call itself. It should be set in the cfgOverrides in the appserver agent configuration (in the directory).

I thought the goal was to let different client to the application server to make the remote calls using its own date format.

No.

Otherwise, the the clients will have to deal with situation, in which local and remove date formats will be different.

Yes, exactly. That is how it works in the 4GL. Setting the value on the client does not set it on the application server.

I suppose, this can cause problems.

If so, it is a problem that the 4GL code was already written to handle.

Note, setting SESSION:DATE-FORMAT on the client also does not affect the date format on the application server agent site.

Good. That is how it is supposed to work.

Vladimir Tsichevski wrote:

I checked that date format can be successfully set in application server by using the cfgOverrides:
[...]

And code that runs there from a remote call does "see" that setting?

Greg Shah wrote:

Vladimir Tsichevski wrote:

I checked that date format can be successfully set in application server by using the cfgOverrides:
[...]

And code that runs there from a remote call does "see" that setting?

Yes, this is exactly what I mean.

9507a was merged to trunk as rev. 15666.

Alexandru Lungu wrote:

9507a was merged to trunk as rev. 15666.

Branch 9398a was merged into trunk as rev. 15667.