FWD » Core Development » Runtime Infrastructure

Spawned appserver clients (and batch processes?) can be configured in the server's directory with a log filename for redirection of stdout.

          <node class="container" name="ffappsrvprocess">
            <node class="container" name="clientConfig">
              <node class="string" name="outputToFile">
                <node-attribute name="value" value="client_%appserver%_%pid%_%timestamp%_%userid%.log"/>
              </node>

If this is present, it is processed by ProcessBuilderParameters.getOutputToFile() on the server before the launch of the spawner. In the above example, the spec is:

client_%appserver%_%pid%_%timestamp%_%userid%.log

3 of the placeholders are processed in ProcessBuilderParameters.getOutputToFile():

%appserver% - comes from the appserver entry in the process account, if it is there
%timestamp% - System.currentTimeMillis(), which seems to be there
%userid% - the FWD process account name, which seems to be there as ffappsrvprocess

The process account:

          <node class="process" name="ffappsrvprocess">
            <node-attribute name="appserver" value="ffappsrv"/>
            <node-attribute name="enabled" value="TRUE"/>
            <node-attribute name="description" value="Process for ffappsrv AppServer."/>
            <node-attribute name="alias" value="ffappsrvprocess"/>
            <node-attribute name="master" value="FALSE"/>
            <node-attribute name="server" value="FALSE"/>
          </node>

So the appserver name should appear as ffappsrv.

But the resulting log names (when the clients are spawned on Windows) are in this form:

client_f11616_1631901774729_ffappsrvprocess.log

The %pid% placeholder is swapped out in the spawner. It looks to me like a portion of the spec (%appserver%_%pid%) converts into f11616 when we would have expected ffappsrv_11616.

I extracted the Linux version of the spawner's replacement code:

#include <stdio.h>
#include <stdlib.h>
#include <string.h>
#include <sys/types.h>
#include <unistd.h>

#define MAX_FILENAME 4096

char* replace_str(char* string, const char* placeholder, char* value)
{
   static char buffer[MAX_FILENAME];
   int len;
   char *p;

   p = strstr(string, placeholder);

   if (!p)
   {
      // placeholder not found
      return string;
   }

   len = p - string;
   strncpy(buffer, string, len); 
   buffer[len] = 0;

   sprintf(buffer + len, "%s%s", value, p + strlen(placeholder));

   return buffer;
}

int main(int argc, char *argv[])
{
   static char buffer[MAX_FILENAME];

   char* string = "client_ffappsrv_%pid%_1631901774729_ffappsrvprocess.log";
   char* placeholder = "%pid%";

   char value[32];

   /* convert pid to string */
   sprintf(value, "%u", getpid());

   char* filename = replace_str(string, "%pid%", value);

   printf("%s\n", filename);
}

When I compile and run this on Linux, the output is OK (client_ffappsrv_148443_1631901774729_ffappsrvprocess.log). I don't have a WIN32 dev environment setup at this time. My best guess here is that the replace_str() function in winspawn.c has some logic problems. This is probably related to the usage of the WIN32 wide character support in that code.

Is string not a pointer to WCHAR? If the contents of string are not wide characters, then that explains the result. For the input string client_ffappsrv_%pid%_1631901774729_ffappsrvprocess.log, the placeholder is found 16 characters in (after client_ffappsrv_). The sizeof(WCHAR) is probably twice as large as the characters in the string, which leads to the len == 8 result.

Code Review Task Branch 3821c Revision 14429

The change is good, however you are missing the history entry.

Greg Shah wrote:

Code Review Task Branch 3821c Revision 14429

The change is good, however you are missing the history entry.

Just pushed it in revision 14430. Bzr commit of a few lines of changes to a local branch is very slow. Is it normal?

I messed up the branch creation / co and pushed from the local branch directly to 3821c. I'll be more careful next time. Btw can you protect 3821c from me until I understand bzr?

1. Post a .diff of your proposed changes in Redmine OR use a task branch that is created specifically off of 3821c.
2. Unbind (bzr unbind) your local copy of 3821c until it is time to commit changes. Any accidental commit will then just be local and won't update the central repo.

Bzr commit of a few lines of changes to a local branch is very slow. Is it normal?

In your current setup, you are just using a local copy bound to the central repo. Any local commit in a "checkout" is modifying the central copy. As noted above, you can unbind to disconnect.

Greg Shah wrote:

In your current setup, you are just using a local copy bound to the central repo. Any local commit in a "checkout" is modifying the central copy. As noted above, you can unbind to disconnect.

I got it, it was just too late. The guide has way too many words and I get lost in it. The create command needs to be executed on the remote server instead on localhost and I didn't get that initially. In git you can create it locally and push/create to the remote.