Hi All;
Has anyone found a way to start WAA1SRV.exe minimized?
Perhaps ... adding a parameter to the "start %1 waa1srv.exe" line of
StartWAA.bat?

Problem: WAA1SRV uses about 14 Mb of memory to start in GUI mode
and about 1.4 Mb after being minimized.
We perform a system restart every morning at 3:00 am to manage memory
leakage.
It takes less than 20Mb of WAA1SRV memory usage to "hang up" (not
responding).
We would like to get through a 24 -hour period with out any human
intervention.

Allen,

> Has anyone found a way to start WAA1SRV.exe minimized?
> Perhaps ... adding a parameter to the "start %1 waa1srv.exe" line of
> StartWAA.bat?
> 
> Problem: WAA1SRV uses about 14 Mb of memory to start in GUI mode
> and about 1.4 Mb after being minimized.
> We perform a system restart every morning at 3:00 am to manage memory
> leakage.
> It takes less than 20Mb of WAA1SRV memory usage to "hang up" (not
> responding).
> We would like to get through a 24 -hour period with out any human
> intervention.

I don't know about starting it up minimised, but you can certainly make it
auto-minimise from one of your pakages as they are loaded.

Give me a few minutes to play and I'll have a solution for you.

Regards,

Phil Ide

***************************************
* Xbase++ FAQ, Libraries and Sources: *
* goto: http://www.idep.org.uk/xbase  *
***************************************

Send your spare mice to SOCKS@WHITEHOUSE.GOV

Allen,

> I don't know about starting it up minimised, but you can certainly make it
> auto-minimise from one of your pakages as they are loaded.
> 
> Give me a few minutes to play and I'll have a solution for you.

This should do what you want, but as Thomas said, it won't really do
anything for you.

Function _register(oPackage)
   MinimiseAppWin()
   return TRUE

Function MinimiseAppWin()
   local oDlg := GetRootWin()

   oDlg:setFrameState(XBPDLG_FRAMESTAT_MINIMIZED)
   return oDlg

 someone forgo to set the WAA console as AppWin(),
 so this routine will find it for you.

Function GetRootWin()
   local oDlg := SetAppFocus()

   While !(oDlg:setParent() == AppDeskTop())
      oDlg := oDlg:setParent()
   Enddo
   return oDlg

Regards,

Phil Ide

***************************************
* Xbase++ FAQ, Libraries and Sources: *
* goto: http://www.idep.org.uk/xbase  *
***************************************

Being a SysOp is nice but it interferes with my life.

Thanks Phil !

I will implement your code just to see the result.
Isn't 16 Mb rather low to be hanging WAA in a server with 2Gb of RAM?

Allen Lee wrote:

> Thanks Phil !
> 
> I will implement your code just to see the result.
> Isn't 16 Mb rather low to be hanging WAA in a server with 2Gb of RAM?

I'm quite sure that the memory leakeage is not the cause for the
hangup... there may be other resources that go down. Maybe you could use
one of the tools at www.sysinternals.com (maybe process explorer) to find
out if the process excessively holds other resources.

Thomas Braun

Allen,

> I will implement your code just to see the result.
> Isn't 16 Mb rather low to be hanging WAA in a server with 2Gb of RAM?

Yes. 7 of my WAA apps run on 2 WAA servers on a single machine with 512Mb
RAM.  They regularly climb to 50Mb (from around 26Mb) during the course of
a day.

I reset them via a schedule twice a day (once in the early evening and once
about 8am) to reclaim that memory.  I also note that as memory usage
climbs, they slow down (no surprise there).

Regards,

Phil Ide

***************************************
* Xbase++ FAQ, Libraries and Sources: *
* goto: http://www.idep.org.uk/xbase  *
***************************************

Down with TLAs! (three letter acronyms)

Phil's code to minimize to WAA window works nicely!
Observation: Although the window is minimized WAA does not release the extra
memory.
It's as if the WAA window is still open according to the Task Manager
The extra memory is not released until the WAA window is minimized manually
by clicking the MIN button in the control box.

Allen Lee wrote:

> Phil's code to minimize to WAA window works nicely!
> Observation: Although the window is minimized WAA does not release the extra
> memory.
> It's as if the WAA window is still open according to the Task Manager
> The extra memory is not released until the WAA window is minimized manually
> by clicking the MIN button in the control box.

From the Microsoft KB article:

> You can write an application that can be minimized without having its
> working set trimmed. To do this, the window procedure for the top-level
> window should intercept the WM_SYSCOMMAND message and respond to the
> SC_MINIMIZE command by calling ShowWindow() directly with the
> SW_SHOWMINIMIZED command. It should not pass the WM_SYSCOMMAND message
> on to DefWindowProc(). 

Maybe SetFrameState uses this approach?

But I think we should try and find out the real cause for the hangup,
which can't be a memory issue IMHO... reading one of your previous
messages, you have plenty of RAM available. I think this is rather a coding
issue than a WAA internal problem.

Thomas Braun

OK, Thomas - it's a coding issue.

There was no XPPERROR.LOG or no XPPFATAL.LOG

For the future, I will change the StartWAA.bat to:
SET WAA_TRACE=ON
SET WAA_INTERNAL_LOG=ON

There is 1 private variable used in 1 function and is released.
All other variables are local.

There are no compile errors and the XPJ compile switches are:
[project]
    COMPILE       = xpp /dll:dynamic /w /wi /wl /wu
    COMPILE_FLAGS = -q
    DEBUG         = yes
    GUI           = no
    LINKER        = alink
    LINK_FLAGS    =
    RC_COMPILE    = arc
    RC_FLAGS      = -v
    PROJECT.XPJ


I will start first by looking at the WAA log file for events preceeding an
unscheduled shutdown.
Then I will use trial and error with Process Explorer from
www.sysinternals.com (thanks)

How would you try to find the offending code?

Allen Lee wrote:

> OK, Thomas - it's a coding issue.
[...]

Just to be sure... you are writing:

> It takes less than 20Mb of WAA1SRV memory usage to "hang up" (not
> responding).

Does "not responding" mean that you need to kill WAA with the task manager
of windows?

> How would you try to find the offending code?

Are you sure that all your form functions are always returning?

I once had a problem where under very specific circumstances (based on the
user input) my program ran into an endless loop.

So after some time, there where no free worker threads left which
effectively stopped WAA.

I would first try to add some of my own logging function so I can see that
all worker threads are returning OK.

Without other information what is going on in your code it is quite a
problem to find out what could go wrong or to give you any useful hints.

Which DBEs are you using, do you dynamically load external DLLs... qustions
like these coming to my mind...

Thomas

Does "not responding" mean that you need to kill WAA with the task manager
of windows? -YES
Which DBEs are you using?-  DBFNTX
Do you dynamically load external DLLs? - NO, only the package DLLs are
loaded at startup

The loop conditions terminate normally under all parameters (I'll check
again)

Question: Could a memo field (ADB->DES) in a loop be causing a problem?

I do this to display a memo field:
1. do while !COU->(eof())
        ...
        oHtml:put('<div>'+trim(ADB->DES)+'</div>')
        ...
     enddo

Do I need to do something like this, instead:
2. local cDES
    do while !COU->(eof())
        ...
        cDES:=trim(ADB->DES)
        oHtml:put('<div>'+cDES+'</div>')
        ...
    enddo

Allen Lee wrote:

> Does "not responding" mean that you need to kill WAA with the task manager
> of windows? -YES

OK, this looks like all worker threads are occupied with doing something.

I think you definately need to add some of your own logging to find out
where the program hangs.

Simple logging can be done with SET ALTERNATE and ?|QOUT(), but the
alternate file is not thread local, so the log output from all threads get
mixed. Much better would be to use fcreate/fwrite to create independent
logs for each thread.

> 
> Question: Could a memo field (ADB->DES) in a loop be causing a problem?

No, I don't think so (unless the database isn't damaged severely)

> I do this to display a memo field:
> 1. do while !COU->(eof())

If the index is damaged, there is a small chance that you will never be
able to leave this loop.


> Do I need to do something like this, instead:
> 2. local cDES

I don't think declaring a local and storing the memo in it content will
help.

Thomas Braun

Allen,

>> Does "not responding" mean that you need to kill WAA with the task manager
>> of windows? -YES
> 
> OK, this looks like all worker threads are occupied with doing something.

ACK.  Something you could also check is that none of your package code hs
an event handler (that would be bad, like crossing the beams!).

Also check for BEGIN SEQUENCE...END SEQUENCE not properly closed.  The WAA
kernel has a SEQUENCE wrapping the call to your form-function, so if a
serious error occurs in your code, it can recover without crashing the
server.

If you hav created a SEQUENCE of your own that doesn't get terminated, then
any error will go into orbit around Titan for a few years.

You might also want to check if you have reset the error-handler if you
have installed your own.  If you do this, it is imperative to restore the
previous error handler when you exit your form-function.

Since you need to use Task Manager to kill WAA, check what the CPU usage on
WAA is before you kill it.  If it is running at nearly 100%, then your
threads are stuck in an endless loop.  If it is 'normal', then your threads
have got themselves stuck in a wait-state (possibly inside an error
handler).

Regards,

Phil Ide

***************************************
* Xbase++ FAQ, Libraries and Sources: *
* goto: http://www.idep.org.uk/xbase  *
***************************************

BBS Trek: The Text Generation

Thanks guys ...  we may have solved this one.

The WAA log showed that multiple worker threads were trying to service the
same form request.
I suspect the origin to be a client repeatedly clicking the submit button on
a particular app web page.

To test that theory, I implemented a javascript function that disables the
submit button after the click event.
The function uses the form elements feature which is supported in IE 4+ or
NS 6+ but I don't know about Opera or Foxfire.
However, that may be enough to stop the hanging because not everybody is
click-happy.

The WAA log error looks like this:
 *** -----------------------------------------------------------
 worker #2 Error:
 ***
e:canDefault   :.F.
e:canRetry     :.F.
e:canSubstitute:.F.
e:description  :
e:filename     :
e:genCode      :0
e:operation    :socket read error
e:osCode       :0
e:severity     :0
e:subCode      :0
e:subSystem    :
e:thread       :2
e:tries        :0
e:cargo        :

Callstack:
CGICHANNEL:DISCONNECT(182)
WAATRANSACT:TEXIT(244)
ENDTRANSACTION(400)
SERVEJOB(335)
SERVEJOBPROTECTION(205)
 *** -----------------------------------------------------------
*** worker #2 Request not completed

Allen Lee wrote:

> Problem: WAA1SRV uses about 14 Mb of memory to start in GUI mode
> and about 1.4 Mb after being minimized.

This is expected behaviour and has to do with the OS's 
memory management, so minimizing will not have the effect you are
expecting:

http://support.microsoft.com/kb/293215/en-us

You can find more details about how the OS manages memory here:

http://www.winntmag.com/Article/ArticleID/3686/3686.html
http://www.winntmag.com/Article/ArticleID/3774/3774.html


HTH
Thomas Braun

Thanks, Thomas
I'll read your references supplied.

What does the Task Manager Memory Usage tab tell us when it displays 15Mb
while the WAA window is open and then minimizing the window immediately
updates the display to 1.4 Mb?

Allen Lee wrote:

> Thanks, Thomas
> I'll read your references supplied.
> 
> What does the Task Manager Memory Usage tab tell us when it displays 15Mb
> while the WAA window is open and then minimizing the window immediately
> updates the display to 1.4 Mb?

It tells you that windows cut down the "working set" of the process.

Thomas Braun

Hello Allen and Thomas,

you can redirect all Window messages to Xbase Parts (I guess the WAA window
is one) with a Cockpit Message Spy and react to them. This would allow you
to prevent the trimming as shown in the code sample.

However, I have not yet tried to use Cockpit with WAA.

Best regards,

Michael.