Beware of accidental stream leaks
Just as it is possible to leak event listeners, it is also possible to leak streams. Suppose that you create a stream but you do not specify the stream as input to any query. This stream still remains in existence, keeps a monitor instance alive, and consumes resources so it is considered to be a stream leak. A stream leak causes memory to be used and not freed. It can also cause unnecessary computation to occur.
A stream leak can happen if you create a stream that you want to use later on in your code. To be able to use this stream, you must assign it to a stream variable that is in scope in the location where you want to use the stream. If the stream variable goes out of scope or you assign another stream to that variable, the original stream still exists within the monitor instance's internal stream network, but it is no longer accessible. For example:
The
stream variable that references the stream goes out of scope:
action streamLeakExample1(string s) {
stream<float> prices :=
from t in all Tick(symbol=s) select t.price;
... // If the elided code does not use the stream
} // a leak occurs when the prices variable goes out of scope.
You overwrite the
stream variable that refers to an unused stream:
action streamLeakExample2(pattern<string> symbols) {
string s;
stream<float> prices;
for s in symbols {
prices := from t in all Tick(symbol=s) select t.price;
... // If the elided code does not use the prices stream
// a leak occurs when you overwrite prices.
}
}
Any code that creates a stream leak is erroneous. Code that repeatedly creates unused, inaccessible streams quickly uses up machine resources. To avoid leaking streams:
Avoid creating streams you do not intend to use immediately.
Quit a stream before the variable referring to it goes out of scope.