flex-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Christofer Dutz <christofer.d...@c-ware.de>
Subject Configuration Options helping BlazeDS clean up lots of Memory
Date Wed, 29 Jul 2015 09:19:49 GMT

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 :-)


  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message