ToolsMenuFunctions/en: Unterschied zwischen den Versionen

Aus expecco Wiki (Version 2.x)
Zur Navigation springen Zur Suche springen
 
(2 dazwischenliegende Versionen desselben Benutzers werden nicht angezeigt)
Zeile 11: Zeile 11:
=== Close all Socket Connections ===
=== Close all Socket Connections ===


Tears down leftover socket connections (interprocess communication).
Tears down all open socket connections (interprocess communication).


=== Close all Serial Connections ===
=== Close all Serial Connections ===


Tears down leftover serial connections
Tears down open serial connections


=== Show Memory Usage by Object Type ===
=== Show Memory Usage by Object Type ===
Zeile 35: Zeile 35:
This is the storage you see when inspecting pin values after an execution. For example, if a socket or file handle is stored in this execution trace, AND this handle was not properly closed (either because the suite simply forgot to close it, or because the test was aborted and the suite provided no close in its post-action), then the handle might be stored in the log, and is therefore never closed automatically.
This is the storage you see when inspecting pin values after an execution. For example, if a socket or file handle is stored in this execution trace, AND this handle was not properly closed (either because the suite simply forgot to close it, or because the test was aborted and the suite provided no close in its post-action), then the handle might be stored in the log, and is therefore never closed automatically.


Notice that this behavior is not a bug: it is often very useful to have external connections still open when looking at the activity-log,
This behavior is not a bug: it is often very useful to have external connections still open when looking at the activity-log,
because in many contexts you can inspect and interact with the connection if it is still open (remember that objects in remote machines are only references via handles, which are invalid, if the underlying bridge connection gets closed). This is especially useful in the inspector tool.
because in many contexts you can inspect and interact with the connection if it is still open (remember that objects in remote machines are only references via handles, which are invalid, if the underlying bridge connection gets closed). This is especially useful for UI connections and in the inspector tool.


In this case, you should either "''Remove all Results in System''" (in the "''Test-Results''"-menu), and then perform a memory cleanup, or use one of the other maintenance functions from the debugging menu to close handles (i.e. "''Close all Sockets''", "''Close all Bridge Connections''", "''Close all Serial Connections''" etc.).
In this case, you should either "''Remove all Results in System''" (in the "''Test-Results''"-menu), and then perform a memory cleanup, or use one of the other maintenance functions from the debugging menu to close handles (i.e. "''Close all Sockets''", "''Close all Bridge Connections''", "''Close all Serial Connections''" etc.).

Aktuelle Version vom 17. Oktober 2019, 22:30 Uhr

These functions are found in the "Extras" → "Debugging" menu.

Show all External Connections[Bearbeiten]

Opens an inspector on all external connections which possibly hold a handle to either a socket, pipe or serialPort. The inspectors presents a list of those connections and a menu function to close them selectively (via the menu or by evaluating "self close" in the inspector). Notice, that all open streams are shown, including stderr and stdout. Do not close those.

Shut Down Bridge Connections[Bearbeiten]

Tears down leftover Java, DotNet, Python, NodeJS and C Bridge connections.

Close all Socket Connections[Bearbeiten]

Tears down all open socket connections (interprocess communication).

Close all Serial Connections[Bearbeiten]

Tears down open serial connections

Show Memory Usage by Object Type[Bearbeiten]

Detailed information about memory usage

Memory Cleanup[Bearbeiten]

Under normal conditions, you don't have to care about expecco's memory: its underlying support system performs automatic memory management (garbage collection). This includes automatic finalization of objects which refer to operating system resources such as file handles, database-connections etc.

However, these finalizations may happen quite delayed, due to the fact that the garbage collector is usually only invoked when running out of memory or when more memory is requested. This means, that if a file- or database handle has not been closed, but is also no longer used by a testSuite, that handle will be closed (and thereby freed) whenever the next garbage collect operation occurs. Which, if no memory is needed for some time, may happen quite delayed.

Another situation in which handles are still referenced (and therefore not closed automatically) is when such handles are still present in an activity-log/trace. Because all data which was interchanged between steps is recorded there, handles may end up being recorded and therefore considered to be still "in-use" by the automatic memory management.

This tool-function forces a garbage collect operation to be triggered immediately, and thereby freeing any unreferenced operating system resources. When those resources get collected, a finalize function is called automatically, which closes the associated operating system handle. Use this, if you have the feeling that the system is using many file, window, socket or other handles.

Notice: the automatic memory management can of course only free memory which is completely unreachable. This means that objects which are still referenced by other referenced objects will not be reclaimed. In expecco, one such "top level" referrer is usually the result log/execution trace of the previous execution(s).

This is the storage you see when inspecting pin values after an execution. For example, if a socket or file handle is stored in this execution trace, AND this handle was not properly closed (either because the suite simply forgot to close it, or because the test was aborted and the suite provided no close in its post-action), then the handle might be stored in the log, and is therefore never closed automatically.

This behavior is not a bug: it is often very useful to have external connections still open when looking at the activity-log, because in many contexts you can inspect and interact with the connection if it is still open (remember that objects in remote machines are only references via handles, which are invalid, if the underlying bridge connection gets closed). This is especially useful for UI connections and in the inspector tool.

In this case, you should either "Remove all Results in System" (in the "Test-Results"-menu), and then perform a memory cleanup, or use one of the other maintenance functions from the debugging menu to close handles (i.e. "Close all Sockets", "Close all Bridge Connections", "Close all Serial Connections" etc.).


Back to Online Documentation.



Copyright © 2014-2024 eXept Software AG