Hi,

Ever since I've upgraded to 1.90 I've had a problem with WAA threads 
hanging.

Everything works for well for a while (usually 1 day) then requests that the 
threads are handling stop completing or take a stupidly long time to finish 
(like 458 seconds instead of 0.42).

WAA also won't shutdown after this happens so I have to terminate the 
program abnormally.

Anyone else had this problem?

Jeremy

Hi Jeremy,
Did you notice WAA memory usage when you terminated it?
We had this issue with 170 WAA, but it is gone with 182.

Vladimir

"Jeremy Suiter" <jeremys@rendallandrittner.co.uk> wrote in message 
news:iHI%23dBF8FHA.5608@S15147418...
> Hi,
>
> Ever since I've upgraded to 1.90 I've had a problem with WAA threads 
> hanging.
>
> Everything works for well for a while (usually 1 day) then requests that 
> the threads are handling stop completing or take a stupidly long time to 
> finish (like 458 seconds instead of 0.42).
>
> WAA also won't shutdown after this happens so I have to terminate the 
> program abnormally.
>
> Anyone else had this problem?
>
> Jeremy
>

I'll check next time it starts playing up.

1.82 was fine, this has only started with 1.90.

Jeremy

"Vladimir Iahnenco" <iahnenco@yahoo.com> wrote in message 
news:T6XlXEG8FHA.1256@S15147418...
> Hi Jeremy,
> Did you notice WAA memory usage when you terminated it?
> We had this issue with 170 WAA, but it is gone with 182.
>
> Vladimir
>
> "Jeremy Suiter" <jeremys@rendallandrittner.co.uk> wrote in message 
> news:iHI%23dBF8FHA.5608@S15147418...
>> Hi,
>>
>> Ever since I've upgraded to 1.90 I've had a problem with WAA threads 
>> hanging.
>>
>> Everything works for well for a while (usually 1 day) then requests that 
>> the threads are handling stop completing or take a stupidly long time to 
>> finish (like 458 seconds instead of 0.42).
>>
>> WAA also won't shutdown after this happens so I have to terminate the 
>> program abnormally.
>>
>> Anyone else had this problem?
>>
>> Jeremy
>>
>
>

Jeremy,

> Ever since I've upgraded to 1.90 I've had a problem with WAA threads 
> hanging.
> 
> Everything works for well for a while (usually 1 day) then requests that the 
> threads are handling stop completing or take a stupidly long time to finish 
> (like 458 seconds instead of 0.42).
> 
> WAA also won't shutdown after this happens so I have to terminate the 
> program abnormally.
> 
> Anyone else had this problem?

I'm not using WAA 1.90, so I haven't.  However, it may be worth checking
your memory usage at interval during the day (no need to be exact, so use
Task manager).  If it continually climbs, you have a problem.

As Vladimir said, this problem occured in 1.70, and so I set a scheduled
task to shutdown and relaunch WAA each morning.  Under 1.82 it isn'
strictly necessary, but I continue to do this because it resolves problems
that may affect persistent threads after some sort of error has occured
(broken socket, unreleased resource-handles after error etc).

Regards,

Phil Ide

*******************************************
*   Xbase++ FAQ, Libraries and Sources:   *
*   goto: http://www.idep.org.uk/xbase    *
* --------------------------------------- *
* www.xodc.org.uk - openSource Dev-Center *
*******************************************

Will that be cache or chkdsk?

I've been doing some investigation and I think I know what the problem is. 
When WAA hangs there's two threads trying to process the same function at 
the same time.  I think people are double clicking pushbuttons.

Jeremy

"Phil Ide" <phil@xodc.org.uk> wrote in message 
news:a7nw4pxsyxda.dlg@xodc.org.uk...
> Jeremy,
>
>> Ever since I've upgraded to 1.90 I've had a problem with WAA threads
>> hanging.
>>
>> Everything works for well for a while (usually 1 day) then requests that 
>> the
>> threads are handling stop completing or take a stupidly long time to 
>> finish
>> (like 458 seconds instead of 0.42).
>>
>> WAA also won't shutdown after this happens so I have to terminate the
>> program abnormally.
>>
>> Anyone else had this problem?
>
> I'm not using WAA 1.90, so I haven't.  However, it may be worth checking
> your memory usage at interval during the day (no need to be exact, so use
> Task manager).  If it continually climbs, you have a problem.
>
> As Vladimir said, this problem occured in 1.70, and so I set a scheduled
> task to shutdown and relaunch WAA each morning.  Under 1.82 it isn'
> strictly necessary, but I continue to do this because it resolves problems
> that may affect persistent threads after some sort of error has occured
> (broken socket, unreleased resource-handles after error etc).
>
> Regards,
> -- 
> Phil Ide
>
> *******************************************
> *   Xbase++ FAQ, Libraries and Sources:   *
> *   goto: http://www.idep.org.uk/xbase    *
> * --------------------------------------- *
> * www.xodc.org.uk - openSource Dev-Center *
> *******************************************
>
> Will that be cache or chkdsk?

I don't think it is possible to execute the same function at the same time. 
You should get function call and thread which executes it in the log. Try to 
replace your function code with some simple one with extra logs and see if 
it gets hung again. From my point of view there is no difference if a user 
double clicked a button, or two users clicked ones at the same time. Your 
function has to work properly in both these cases. Else check if you lock 
records, databases ... that may cause both threads to wait each other.

Vladimir

"Jeremy Suiter" <jeremys@rendallandrittner.co.uk> wrote in message 
news:2YCHHnR8FHA.2944@S15147418...
> I've been doing some investigation and I think I know what the problem is. 
> When WAA hangs there's two threads trying to process the same function at 
> the same time.  I think people are double clicking pushbuttons.
>
> Jeremy
>
> "Phil Ide" <phil@xodc.org.uk> wrote in message 
> news:a7nw4pxsyxda.dlg@xodc.org.uk...
>> Jeremy,
>>
>>> Ever since I've upgraded to 1.90 I've had a problem with WAA threads
>>> hanging.
>>>
>>> Everything works for well for a while (usually 1 day) then requests that 
>>> the
>>> threads are handling stop completing or take a stupidly long time to 
>>> finish
>>> (like 458 seconds instead of 0.42).
>>>
>>> WAA also won't shutdown after this happens so I have to terminate the
>>> program abnormally.
>>>
>>> Anyone else had this problem?
>>
>> I'm not using WAA 1.90, so I haven't.  However, it may be worth checking
>> your memory usage at interval during the day (no need to be exact, so use
>> Task manager).  If it continually climbs, you have a problem.
>>
>> As Vladimir said, this problem occured in 1.70, and so I set a scheduled
>> task to shutdown and relaunch WAA each morning.  Under 1.82 it isn'
>> strictly necessary, but I continue to do this because it resolves 
>> problems
>> that may affect persistent threads after some sort of error has occured
>> (broken socket, unreleased resource-handles after error etc).
>>
>> Regards,
>> -- 
>> Phil Ide
>>
>> *******************************************
>> *   Xbase++ FAQ, Libraries and Sources:   *
>> *   goto: http://www.idep.org.uk/xbase    *
>> * --------------------------------------- *
>> * www.xodc.org.uk - openSource Dev-Center *
>> *******************************************
>>
>> Will that be cache or chkdsk?
>
>

Jeremy,

> I've been doing some investigation and I think I know what the problem is. 
> When WAA hangs there's two threads trying to process the same function at 
> the same time.  I think people are double clicking pushbuttons.

That shouldn't hang the application or any of it's threads.  What should
happen is the first click gets aborted by the browser, in which case the
function should run to termination and then the result should be discarded
automatically by WAA.

What may be an issue, is if your function does something it should only do
exclusively.  Things to watch out for:

1. Opening tables exclusive
2. Creating temporary tables/files with explicit names
3. adding/deleting elements from a STATIC array
4. assigning/discarding values in STATIC, PUBLIC or PRIVATE vars
5. significantly changing properties of class objects (not instances)

Regards,

Phil Ide

*******************************************
*   Xbase++ FAQ, Libraries and Sources:   *
*   goto: http://www.idep.org.uk/xbase    *
* --------------------------------------- *
* www.xodc.org.uk - openSource Dev-Center *
*******************************************

If you hit every time, the target's too near.

I'm sure it is the WAA application itself that is messing around.

It's not related to one function it'll  freeze no matter what it's asked to 
process.
STATIC, PUBLIC or PRIVATE vars and I'm not using classes at all.

All this worked perfectly with no problems with 1.82 so I'm sure it's 
somethng to do with 1.90.  When it does freeze it's not hogging memory 
either.

At the moment I'm down to about 1 hour before it stops working.

Jeremy

I don't exclusively open tables or create temporary ones and neither do I 
use
"Phil Ide" <phil@xodc.org.uk> wrote in message 
news:qz0d2wodfbgw$.dlg@xodc.org.uk...
> Jeremy,
>
>> I've been doing some investigation and I think I know what the problem 
>> is.
>> When WAA hangs there's two threads trying to process the same function at
>> the same time.  I think people are double clicking pushbuttons.
>
> That shouldn't hang the application or any of it's threads.  What should
> happen is the first click gets aborted by the browser, in which case the
> function should run to termination and then the result should be discarded
> automatically by WAA.
>
> What may be an issue, is if your function does something it should only do
> exclusively.  Things to watch out for:
>
> 1. Opening tables exclusive
> 2. Creating temporary tables/files with explicit names
> 3. adding/deleting elements from a STATIC array
> 4. assigning/discarding values in STATIC, PUBLIC or PRIVATE vars
> 5. significantly changing properties of class objects (not instances)
>
> Regards,
> -- 
> Phil Ide
>
> *******************************************
> *   Xbase++ FAQ, Libraries and Sources:   *
> *   goto: http://www.idep.org.uk/xbase    *
> * --------------------------------------- *
> * www.xodc.org.uk - openSource Dev-Center *
> *******************************************
>
> If you hit every time, the target's too near.

Jeremy,

> I'm sure it is the WAA application itself that is messing around.
> 
> It's not related to one function it'll  freeze no matter what it's asked to 
> process.

Ok, create a seperate logging file and log to it when you enter and leave
any suspect function.  Here's a the layout of my logs:

date time thread-id package function text duration

...where text is either "enter" or "exit", and duration is only added on
exit.

You'll find a logging function very handy when debugging.  This is the one
I use for debugging and recording errors.  It's handy because it places new
entries at the top of the file - not very efficient, but handy.

#define LBREAK    chr(1)
#define CRLF      chr(13)+chr(10)

Function LogTransaction(cReason)
   local cLog := 'logs\cn'+dtos(date())+'.log'

   cReason := StrTran( cReason, LBREAK, CRLF+Space(20) )
   cReason := dtos(Date())+' '+;
              time()+' '+;
              (#'+LTrim(StrZero(ThreadID(),2))+'): '+;
              httpDefVar(WAA_PACKAGE,'')+' '+;
              ProcName(1)+' '+;
              cReason+CRLF

   cReason := cReason+StrTran(MemoRead(cLog),chr(26),'')
   memowrit(cLog,cReason)
   return (Nil)

Regards,

Phil Ide

*******************************************
*   Xbase++ FAQ, Libraries and Sources:   *
*   goto: http://www.idep.org.uk/xbase    *
* --------------------------------------- *
* www.xodc.org.uk - openSource Dev-Center *
*******************************************

Does the name "Pavlov" ring a bell?

I need to do something to check so I'll give it a go and se what happens.

Jeremy

"Phil Ide" <phil@xodc.org.uk> wrote in message 
news:1pv76hc72b79k.dlg@xodc.org.uk...
> Jeremy,
>
>> I'm sure it is the WAA application itself that is messing around.
>>
>> It's not related to one function it'll  freeze no matter what it's asked 
>> to
>> process.
>
> Ok, create a seperate logging file and log to it when you enter and leave
> any suspect function.  Here's a the layout of my logs:
>
> date time thread-id package function text duration
>
> ...where text is either "enter" or "exit", and duration is only added on
> exit.
>
> You'll find a logging function very handy when debugging.  This is the one
> I use for debugging and recording errors.  It's handy because it places 
> new
> entries at the top of the file - not very efficient, but handy.
>
> #define LBREAK    chr(1)
> #define CRLF      chr(13)+chr(10)
>
> Function LogTransaction(cReason)
>   local cLog := 'logs\cn'+dtos(date())+'.log'
>
>   cReason := StrTran( cReason, LBREAK, CRLF+Space(20) )
>   cReason := dtos(Date())+' '+;
>              time()+' '+;
>              (#'+LTrim(StrZero(ThreadID(),2))+'): '+;
>              httpDefVar(WAA_PACKAGE,'')+' '+;
>              ProcName(1)+' '+;
>              cReason+CRLF
>
>   cReason := cReason+StrTran(MemoRead(cLog),chr(26),'')
>   memowrit(cLog,cReason)
>   return (Nil)
>
> Regards,
> -- 
> Phil Ide
>
> *******************************************
> *   Xbase++ FAQ, Libraries and Sources:   *
> *   goto: http://www.idep.org.uk/xbase    *
> * --------------------------------------- *
> * www.xodc.org.uk - openSource Dev-Center *
> *******************************************
>
> Does the name "Pavlov" ring a bell?