Home Server
New Blog Posts: Merging Reports - Part 1 and Part 2

Reports generated after restart of RBServer.exe

edited October 2006 in Server
?After successfully generating and viewing a report, I stopped the
rbServer executable, cleared the contents of my Cache directory and
restarted the rbServer executable. I noticed that before another report
was requested, a new entry was made in the Cache directory containing
the report that was previously generated. After duplicating this
scenario numerous times and comparing the web server logs with the
rbserver logs, it seems that a request with the same report parameters,
soap id, etc are being re-requested upon the session timeout of the
webtier.

Does the webtier session need any type of free/destroy statements to
prevent the duplication of reports? Has anyone else experienced anything
like this before?



--- posted by geoForum on http://delphi.newswhat.com

Comments

  • edited October 2006

    - if you want to restart everything, you need to stop the report server
    /and/ the webtier

    - the webtier maintains a cache of web sessions that corresponds to the
    browser clients. The web cache for a single web session will have
    subdirectories for reports that have been requested and for the report
    server session id that it is using. (Keep in mind that the webtier acts as a
    client to the report server)

    - I am unable to follow your description of what you are testing and what is
    happening.

    --
    Nard Moseley
    Digital Metaphors
    www.digital-metaphors.com

    Best regards,

    Nard Moseley
    Digital Metaphors
    www.digital-metaphors.com
  • edited October 2006
    What I was originally testing was report generation times. The details
    of my events are as follows:

    Send a report request to the webtier. (https://dirStructure/webTier.dll)
    Record time that report was generated.
    After viewing the report, stop the rbServer.exe.
    Delete entire contents of the Cache directory structure.
    Close browser. I was assuming that the closing of the browser stops the
    webTier session.
    Restart the rbServer.exe

    With no additional report requests sent, browsers closed, etc, a new
    report would be generated within the Cache directory structure. This
    unrequested report will generate 5 minutes (current session timeout
    value) after the timestamp of the first report that was requested. Since
    the executable had been stopped and restared, I am assuming that the
    webTier was not really released upon closing of the browser. I did
    verify that my Free statements in the webtier code are being triggered,
    so I am unusure of when the webtier is actually being released.

    This seems to only happen when multiple reports are requested from more
    than a single machine. I have not been able to duplicate this when all
    report request originate from the same machine, but only when requesting
    from multiple machines simultaneously. Also, this only occurs when the
    webtier dll is requested directly in the URL
    (https://dirStructure/webTier.dll). Since our application involves an
    ASP.NET front end application to allow end user selected parameters to
    be sent to the report, (i.e. webTier.dll?myParams=123) the webtier.dll
    is not actually requested in in a https:// request, but is referenced as
    a relative link from the asp.net application.
    (../dirStructure/webtier.dll)

    Since this only occurs when being requested directly from the URL, it
    does not create a direct problem to our application, but does leave some
    unanswered questions about the communications between the dll and the
    executable.

    I would have thought that if the rbserver.exe has been stopped and
    restarted, and the webtier makes a request upon timeout, that the soap
    id would be invalid at this point and not allow the generating of the
    report. From your statement that the webTier is a client of the server
    executable, that the existing connection between rbServer and the
    webTier would no longer be valid. From the above described scenario,
    this does not seem to be the case since the soap id contained in the
    unrequested report was the same soap id in the requested report.

    Exactly when and under what conditions is the webtier freed?
    Does the rbserver.exe need to be running to achieve the freeing of the
    webtier?
    Is there something else I should be looking at concerning this?


    as a
    what is



    --- posted by geoForum on http://delphi.newswhat.com
  • edited October 2006

    The report server and webtier each manage persistent sessions that implictly
    time out if a client does not make another request in a specified amount of
    time. (the session time out).

    The report server typically runs within the context of a Windows Service.

    The webtier typically runs within the context of a web application.The
    webtier is loaded by the web application and is never unloaded unless you
    explicity stop the web server. (Or in the case of ISAPI applications, you
    can use IIS manager to unload them).

    If you are using ASP.NET, then you are building an ASP.NET module (dll)
    that is going to use the WebTier as a COM object - which means that is it
    implicitly loading the WebTier (dll). The webtier will not be unloaded
    unless you unload the ASP.NET module. (I do not recall the specifics about
    how this is done in the .NET environment).

    The report server and webtier can run on the same machine or on different
    machines.

    The webtier maintains a web cache that includes the soap id it uses to
    commicate with the server and cached content (i.e. html pages). You can use
    the WebTier SessionOptions to control how many reports are cached for each
    user session and to control the session time out value. The
    GarbageCollection settings are used to control how often the timed sessions
    are cleaned up (deleted). You can use Windows Explorer to browse the
    CacheDirectory and check out the cached information.


    --
    Nard Moseley
    Digital Metaphors
    www.digital-metaphors.com


    Best regards,

    Nard Moseley
    Digital Metaphors
    www.digital-metaphors.com
  • edited November 2006
    Our ASP.NET application is a seperate app used only for the end user
    selection of parameters to be passed to an ISAPI webtier. It runs
    totally independant of the webtier/rbserver configuration.

    In this particular case, it seems that the webtier was still loaded
    since I did not restart the IIS services but only the rbServer, but I am
    still not sure why upon the timeout of the webtier session that a
    request was made instead of the session simply being dropped by the
    webtier since the Cache directory had been emptied (manually deleted by
    me through Windows Explorer).

    Any thoughts?


    implictly
    amount of
    Service.
    you
    you
    (dll)
    it
    about
    different
    use
    each
    sessions
    (https://dirStructure/webTier.dll)
    the
    Since
    triggered,
    more
    requesting
    as
    some
    server
    the
    acts



    --- posted by geoForum on http://delphi.newswhat.com
  • edited November 2006

    report server <----> webtier <---------------> web browser clients
    - session cache - web session cache

    If you shut down the report server, the webtier will have no knowledge about
    that. There is not a persistent connection between the two.

    The WebTier has its own cache that it maintains for its web browser clients.
    Part of the cache info that it maintains for each web browser client is the
    SoapId that is used to communicate with the report server. Therefore if you
    shut down the report server and bring it back up, the WebTier will keep
    using the SoapID that it has cached.

    You can use Windows Explorer to view the Cache directory maintained by the
    WebTier.




    --
    Nard Moseley
    Digital Metaphors
    www.digital-metaphors.com

    Best regards,

    Nard Moseley
    Digital Metaphors
    www.digital-metaphors.com
This discussion has been closed.