Hi,
While investigating a reported memory leak in https://issues.apache.org/jira/browse/FLEX-34648 I discovered, that the reported leak isn't in fact a leak, but more BlazeDS has some default settings that are less than ideal. There are one or two issues which will be addressed by the upcoming version 4.8.0 but I thought I'd post my findings here. It solved almost all of my memory problems with a BlazeDS solution of mine and it explained a lot of things I didn't quite understand. I created a small BlazeDS server and flex client application where on the server a component generates messages every millisecond. My observation was that as long as no connection from a client is initiated, the memory consumption stays low. As soon as a Client connects and subscribes to the topic, it stays low. But as soon as a client is simply killed, the memory consumption on the Server grows till it dies of an OutOfMemory error. So now to the explanation of what's happening: If the FlexClient subscribes to a destination, a queue of messages will be maintained containing references to the messages that he didn't get yet. While the client is connected, he periodically/or continuously drains this queue. As soon as the Client dies, this queue is not drained and it keeps on growing. BlazeDS doesn't automatically invalidate inactive FlexClient instances. This only happens if you explicitly set the flex-client elements "timeout-minutes" to a value greater than 0 (0 is the default) (See the linked issue for details). As soon as I set this property to a value greater than 0 I can see the memory consumption growing untill the client is invalidated, but it doesn't drop ... it simply stops growing. It turns out that unfortunately when invalidating a FlexClient, that clients destination subscriptions are not automatically cleared (This is actually a bug and will be fixed in 4.8.0). So even if the FlexClient is invalidated, the messages to destination he subscribed to will not be cleared. That's why you can observe the memory consumption staying at the level of when the client disconnected. In order to have these queues automatically cleared, you need to set the "subscription-timeout-minutes" to a value greater than 0 (0 is the default). As soon as this is done the Queues and the Messages they contain are correctly garbage collected after the given timeout. Last problem was related to the message-timout of the messages themselves. It seems this timeout is only checked and expired messages are invalidated when draining the queues. If the client simply disappears, no drain is performed and the messages are not invalidated (This will also be fixed in 4.8.0). So don't be surprised that Messages aren't cleared automatically. This only works as long as the client is actually connected. So hopefully this will help the one or the other using BlazeDS :-) Chris
