Use the information in this section to troubleshoot problems related to installing, configuring, and using CX RealiTea Viewer.
Images not displaying in CX RealiTea Viewer
In order for images to display in CX RealiTea Viewer, the
in a REQ must be resolvable to a name that can reach the original Web server from the desktop where CX RealiTea Viewer is running. If this is not the case, the images are not displayed.
For example, if SERVER_NAME is company.com but the desktop must use
http://www.company.com/ to reach the website, then Viewer is not able to get the image.
To fix this issue, you can use the Viewer Profile server remapping option:
- In RTV, select View > Options > Profile > Edit Profile
- Create a stanza that is named company.com. This value should match the string found in SERVER NAME.
- Under this stanza, create a line:
- Save the profile changes and exit the options dialog. The replay should redraw, and the images are present.
Every captured Web server must have a stanza in the profile. If there are 5 servers being captured, each of five stanzas must have
SERVER NAME=www.company.com added to the profile. For example, if the SERVER_NAME in the REQs are
web3, etc. then there must be a section for each;
Missing pages when replaying sessions
On occasion, some pages might be missing from session replay. Use this topic to understand the possible causes of missing pages.
For sessions that appear to be missing pages, the following are the most likely causes:
- The Viewer may be configured to not replay the page. To resolve this issue:
- Acquire the full URL of the page, including file extension.
- Check the Viewer's option for Interpreted Pages.
- Verify the file type that you want to replay has a check mark by its extension.
- Review the Viewer's option for Profile to ensure that the URLS of the missing pages are not listed in an IGNOREURL line.
- If you use a CX Passive Capture Application server (PCA server):
- There may be a Web server that the PCA server was not configured to capture on the Interface page of the PCA servers Web UI.
- The missing pages are of Binary file type. To determine:
- Create a session for yourself. On the pages that are missing from replay, what is the file extension of the pages? Does it match an extension found in the ExcludeExtensions list on the Miscellaneous page of the PCA servers Web UI?
- If so, remove the extension from the ExcludeExtensions list and click Save Changes (preferably when Web traffic is low to minimize the disruption to data capture).
- There may be an issue with the input data to the PCA servers capture NIC(s).
- If you can define a session-level event that recognizes the absence of the page(s), then you can do a focused TCPDump to determine whether there is such an issue. Start a TCPDump run (output to a file) at a time of day when this issue is most likely to occur. If you can filter the traffic by Web server IP address or at least IP port number, that can help keep the size of the output file from growing too quickly.
- After making the above changes, observe the Portal for the occurrence of the missing-page event. After the event was seen, the TCPDump run can be stopped. You can then retrieve the session that fired the event, get the REMOTE ADDR (client IP address) from it, and filter the TCPDump output file to create a much smaller file for analysis of whether the page is missing because the input data to the PCA server is missing some data .
This procedure is more complicated if the Web traffic of interest is HTTPS. In that case, you must verify that the beginning of the captured session that occurred after the beginning of the TCPDump run to ensure that the TCPDump output contains the initial SSL handshake. Capture of this handshake data is crucial to decrypting the captured data for analysis. If using IIS capture filter:
- There is a Web server whose capture filter is not installed/not working/can't connect/has insufficient bandwidth to Tealeaf server/experiences intermittent network faults to the Tealeaf server. In this case, the solution is to review the Windows™ Application Event Log of each Web server to ensure the filter is running correctly on each.
- The missing pages are of the Binary file type. To determine if this is the case, manually drive a session. On the pages that are missing from replay, what is the file extension of the pages? Does it match an extension found in the
TealeafIIS.cfgfile's ExcludeExtensions list? If so, remove the extension from the ExcludeExtensions list in the
.cfgfile on each Web server and restart IIS to reload the
.cfgfile (preferably when Web traffic is very low).
Embedded .pdf documents opening in separate window
If .pdf documents are opening in a separate window instead of in the Viewer, you can set a property so that the .pdf file opens as an embedded document.
In the Internet preferences of Adobe™ Reader, there is a setting to open the
Missing .css files in sessions
Cascading Style Sheets (
.css) are considered static content. Depending on how your Tealeaf environment is configured, some or all of the following file types may be dropped from capture:
.au, .avi, .bin, .bmp, .cab, .class, .css, .dcr, .doc, .exe, .gif, .gz, .htc, .htrc, .jar, .jpeg, .jpg, .js, .mov, .mp3, .mp4, .mpe, .mpg, .pdf, .png, .ppt, .ra, .ram, .rar, .rm, .rtf, .snd, .swf, .tif, .tiff, .wav, .xls, .zip, .ico
The above list of file extensions identifies many common types of binary files, which may be managed through the following mechanisms:
- PCA: Through the Pipeline tab in the PCA Web Console, you can configure the following methods of managing binary content:
- Captured files whose extensions are present in the Excluded Extensions list are automatically dropped by the PCA.
- You can configure the PCA to drop responses that are identified as images.
- Windows Pipeline:
- When enabled in the Data Drop session agent, DelImages discards image data in the Windows pipeline, so that repeating static content is not stored in the session.
- Optionally, you can configure a static archive to capture and store static content, so that you retain a permanent snapshot of captured sessions.
Note: When a static archive is deployed, DelImages must be disabled.
Depending on how your Tealeaf environment is configured, static content, including style sheets (
.css files) may be dropped during processing. When a file extension was configured to be dropped, Tealeaf discards the response.
Each page may make multiple requests for these files, so storing every successful hit of these types can waste space in the database and the indexes. These static files rarely change. Unless there is a specific error, it is more sensible to assume that they were successfully delivered.
CX RTV crashes after hours of use
If you open CX RTV in the morning and spend hours searching and replaying sessions, CX RTV consumes large amounts of disk space in its temporary directory. After hours of use, the CX RTV application window may suddenly disappear.
CX RTV downloads all hits for a session when doing replay. When doing searches, it must download the specific hits that match the search.
If CX RTV crashes after hours of use:
- Try to make your searches more restrictive. The benefits are twofold:
- Searches finish faster.
- The result sets consume less memory on the computer running CX RTV.
- After searching, wait for the hit results to be displayed before starting replay. Click Cancel in the upper right of the CX RTV search results screen while CX RTV is downloading individual hits to jump straight to replay.
- Take a break every hour or so or after replaying a score of sessions to close CX RTV and reopen it. This restart allows CX RTV to free up space from its memory and disk caches.
HTTP status code=0
HTTP StatusCode=0 is associated with incomplete capture of a hit or page and often with a labeling of the hit as "request canceled" (
Request cancellation as interpreted by the passive capture software can occur in a number of ways:
- The visitor clicked the Back button or clicked a visible link before a page finished rendering.
- The visitor could explicitly click the Stop button in the browser or press the
Esckey on the keyboard or similar.
- The actual length of the request or response data may differ from the value that is specified in the HTTP Content-Length header. The client or server closing the TCP/IP connection, miscalculation and misreporting of the content length by the Web server, or complete absence of the Content-Length header can cause this effect.
HTTP status code 304 and cached objects
If supported as an option, the Web server can return an HTTP status code 304, to tell the browser to use its local cached copy.
As part of a GET request, the browser can include a header that is called
- The Request view of a Tealeaf-captured hit displays it as
HTTP IF MODIFIED SINCE. Along with this header is a date indicating when the object was cached. It is up to the Web server to look for this header and compare the date in it to the last-modified date of the requested resource. Most Web servers support this option.
If the Web server supports this option, it can return an HTTP status code 304, to tell the browser to use its local cached copy. This interaction between Web browser and server still results in a REQ/RSP pair with a zero-length response body. This sequence of events is different from hitting the browser's Back button and getting a page from local memory cache with no REQ being issued to the Web server.
The browser only includes the
If-Modified-Since header in its request if it finds a copy of the object in its local cache, so this behavior should only apply to files that can be cached.
The cache is not necessarily the in-memory cache, although it is entirely up to each browser how it is handled. In the case of Internet Explorer, the cached files are stored as Temporary Internet Files on the local disk and remain until you explicitly delete them in Internet Options. So, quitting out a browser and reopening does not avoid 304's.
If you have selected the
Load Remote 304 Pages check box in the Replay options tab, it runs a simple GET request that does not include the
If-Modified-Since header, so that the Web server returns the object rather than a 304 response. However, the Viewer may not retrieve the same object that the original visitor saw. Any redirection that occurs as a result, such as to the home page, is not immediately obvious when replaying a session, which is why that option is usually disabled.
Viewer incorrectly showing Back button pressed on several pages
The Viewer assumes that the browser's Back button was used whenever the Referer of the current page is not the URL of the page immediately previous in the session.
To address this issue:
- To turn off Back button insertion, select View > Options.
- Select the Replay tab
- Clear the Insert Back Pages check box.
HTTP headers displaying in Replay view
There might be instances where HTTP headers are displayed in Replay view. To address this issue, use the procedure documented here.
- In RTV, select View > Options.
- Click the Replay tab.
- Set the HTTP Header Skip setting to
Unavailable event icons in an all-in-one or stand-alone Portal Server deployment
If event icons are unavailable in an all-in-one or stand-alone Portal Server deployment, follow the procedure documented here.
- Run RegEdit on the Portal server.
- Navigate to the following:
HKEY LOCAL MACHINE\ SOFTWARE\TeaLeaf Technology\DataStore\SearchServer
- The EventImagesPath should be the full path of your ...\TeaLeaf\Portal\WebApp directory.
Unavailable event icons issue in a multi-server deployment
If event icons are unavailable in a multi-server deployment environment, follow the procedure documented here.
- Log in to the Portal as an administrator.
- From the Portal menu, navigate to TMS.
- In the WorldView tab, select a server that hosts a Canister (Processing Server).
- Open the Search Server node.
- Click the Search Server configuration node.
- Click View/Edit.
- Enter the appropriate value for the Portal Server.
- Save your changes.
- If there are multiple Canisters in the environment, repeat the above TMS steps for each Canister.
- Configure a job to push the changes to the Canister server or servers.
IgnoreURL rule merges the event list with the page list
On rare occasions, the IgnoreURL rule causes the event list to be merged with page list.
If you have created a new IgnoreURL rule, you may notice that the event list merged with the page list. This happens infrequently.
The issue can be corrected by completing the following steps:
- If you have unsaved changes in your session, save it.
- Close the session.
- Reopen it.
The panes are separated, as normal.
You can assess the cause of
TeaLeaf_Client_tlGetNodeFromXPath errors as described here.
During replay of a session, the following error may be displayed:
This error may be caused by one of the following causes:
- Scripts that are not permitted to run in CX RealiTea Viewer: CX RealiTea Viewer must be configured to replay scripts embedded in a session. Verify the following:
- From the RTV menu, select Tools > Options.
- Click the Replay tab.
- Select the
Allow Scripts to Runcheck box.
- Click OK.
- Improperly formatted HTML pages: In the session, the above error message may appear on only some of the responses. Check the following:
- Open the session.
- Click the Replay tool in the toolbar.
- In the Viewable Pages list, select one of the pages where the error occurs.
- Right-click the replay pane and select View Document Source....
- The response is displayed. If this page is an HTML page, the page should have the following basic structure. Verify that the following tags are present and listed in the displayed order, ignoring the content between them:
<HTML> <HEAD> (header content) </HEAD> <BODY> (body content) </BODY> </HTML>
- If the above structure is not present in the displayed page, the web application may not be properly constructed the selected page. Save the source page displayed in
Notepad.exeto your local computer and provide it to your web application development team.
"Would you like to remove" continues to appear even after CX RTV uninstalled
If you uninstalled CX RTV and are attempting to reinstall, you might receive the "Would you like to remove" dialog, even though RTV components were already removed.
The issue is caused by the presence of an InstallShield installation information folder; Windows Explorer may fail to display the folder, making it easy to miss when trying to manually clean up after the uninstall.
- On your local machine, navigate to the following directory:
- In the Windows Explorer menu, select Tools > Options.
- Click the View tab.
- Underneath the Hidden Files and Folders node, select
Show hidden files and folders.
- Click OK.
- In the
Program Filesfolder, the
InstallShield Installation Informationfolder should now be visible.
- In each subdirectory of the
InstallShield Installation Informationfolder, open and read the contents of the setup.ini file. When you find the subdirectory containing the RTV installation information, delete that entire subdirectory.
Please sign in to leave a comment.