Session Manager in 15.2.69 stops working sometimes

[Alexandre Machado]

That would be very welcome, thank you very much!

By adding logging, do you mean logging that we can see using the new IntraWeb Server Monitor? Or in another way?

Yes, the session timout thread will trigger the TIWExceptionLogger which is responsible for collecting exception information and saving the detaild report (which can be used by IW Server Monitor as well).

[Alexandre Machado]

When you say you get an AV, where exactly does it happen? Do you have the call stack (the exception logger, if active, should contain all details about it).

We get an "Invalid Pointer Operation" in the TIWForm.Dispose calling inherited Dispose:

Code:

TIWForm.Dispose inherited dispose
[000000005EDE9A63] System.ErrorAt
[000000005EDE9AB1] System.Error
[000000005EDE97D1] System.@FreeMem
[000000005EE1FFEA] System.SysUtils.StrDispose
[000000005F10BEC9] Vcl.Controls.TControl.Destroy
[00000000607CDA64] IWVCLBaseControl.TIWVCLBaseControl.Destroy (Line 176, "IWVCLBaseControl.pas")
[000000005EDEEED8] System.TObject.Free
[00000000607AACFB] IWContainer.TIWContainer.Dispose (Line 545, "IWContainer.pas")
[00000000607CE8E0] IWFormDsn.TIWModuleDsn.Dispose (Line 139, "IWFormDsn.pas")
[00000000607D12CD] IWBaseForm.TIWBaseForm.Dispose (Line 494, "IWBaseForm.pas")
[000000005FE6F569] IWBaseHTMLForm.TIWBaseHTMLForm.Dispose (Line 90, "IWBaseHTMLForm.pas")
[00000000607BFB5B] IWForm.TIWForm.Dispose (Line 523, "IWForm.pas")
[000000006064A8B3] UnitCaiwBaseForm.TIWCaiwBaseForm.Dispose (Line 1653, "UnitCaiwBaseForm.pas")
[000000005F1E3C66] IWVCLBaseContainer.TIWBaseContainer.Destroy (Line 228, "IWVCLBaseContainer.pas")
[00000000607D0E7D] IWBaseForm.TIWBaseForm.Destroy (Line 394, "IWBaseForm.pas")
[00000000607BF0CF] IWForm.TIWForm.Destroy (Line 361, "IWForm.pas")
[00000000606496D4] UnitCaiwBaseForm.TIWCaiwBaseForm.Destroy (Line 1541, "UnitCaiwBaseForm.pas")
[000000005EDEEED8] System.TObject.Free
[000000005EF25C8F] System.Classes.TComponent.DestroyComponents
[000000005EF2547F] System.Classes.TComponent.Destroy
[00000000607D9C0E] IWApplication.TIWApplication.Destroy (Line 819, "IWApplication.pas")
[000000005EDEEED8] System.TObject.Free
[000000005F1D75C7] IWServerControllerBase.TSessionTimeoutThread.DoExecute (Line 1658, "IWServerControllerBase.pas")
[000000005EFABE2C] IW.Common.Threads.TIWTimedThread.Execute (Line 228, "IW.Common.Threads.pas")
[000000005EF23263] System.Classes.ThreadProc
[000000005EDF224D] System.ThreadWrapper
[00007FFC896C4DE0] BaseThreadInitThunk
[00007FFC8ABBED9B] RtlUserThreadStart
: Invalid pointer operation

Hi Dr. Bob,

From your call stack it's clear to me that the exception affected the session timout thread. I'll have to revisit the code of this version and check why it happened. At least the call stack is very clear about this, which is good..

It there anything special regarding this form in your application? Maybe some dynamic components being created/destroyed or changing parents at runime (e.g. IWGrids)?

TIWCaiwBaseForm

It would be good to also understand why the exception happened. Seems that a TIWVCLBaseControl (any TIWControl descendant basically) raised that exception when being destroyed. It smells like it has been already destroyed previously, before the actual form destruction.

Thanks for the valuable information

[Alexandre Machado]

As I mentioned before, this is the code that destroys the IWApplication instance. It is protected with a try..except block so any exception that happens when destroying the application instance won't affect the thread execution sequence (this is version 15.2.69 code):

   

How did you obtain the stack trace? Did it happen while debugging or you have an extra tool (MadExcept, EurekaLog, your own code...)?

Cheers,

[ebob42]

We use the IWJclDebug, and IWJclStackTrace, units, and these return the stacktrace that I included. They are always pretty accurate.

---

I need to add that we've modified some of the IntraWeb source code files, as mentioned in https://www.atozed.com/forums/thread-302...10379.html

I've made changes to IWControls.pas and IWForms.pas

The biggest change is inside procedure TIWCustomControl.Dispose(ADispose: Boolean); where I've chanhed the 2 lines

Code:

    if not IsDesignMode then begin
      UnRegisterAsyncEvents;

into

Code:

    if not IsDesignMode then
    try
      if (OwnerForm <> nil) and
        (OwnerForm is TIWForm) and
          Assigned((OwnerForm as TIWForm).PageContext) and
          not (OwnerForm as TIWForm).PageContext.Destroying then
      try
        UnRegisterAsyncEvents
      except
        on E: Exception do
          CodeSite(S_OOP).LogException('procedure TIWCustomControl.Dispose - UnRegisterAsyncEvents', E);
      end;
    except
      on E: Exception do
        CodeSite(S_OOP).LogException('procedure TIWCustomControl.Dispose - OwnerForm/PageContext', E);
    end;

[Alexandre Machado]

After some thought and discussion we have some new features that we decided to implement. Among them:
- inclusion of session timeout thread data into the performance data collected by IWServerMonitor
- creation of a sentinel thread to monitor the server internal workings. The first task of this thread would be watch closely the session timeout thread and make sure that it's always up and running.

The first measure will allow users to have more details about the internal workings of the session thread (when ithe thread ran for the last time/number of destroyed sessions)
The second measure will prevent that external unpredictable factors interrupt the service threads. Other minor changes are also being implemented.

[Alexandre Machado]

Please see my notes here regarding your code changes:

https://www.atozed.com/forums/thread-302...l#pid11821