Announcement

Collapse
No announcement yet.
X
  • Filter
  • Time
Clear All
new posts

    v6.5 - messaging memory leak?

    Setup:

    ActiveMQ with topic called testmsgChannel.
    I send to that topic about 6000 message per hr with avg message size under 1k.

    Using the smartclient version 6.5,
    In the client, I subscribed as:

    Messaging.subscribe("testmsgChannel", "messaging_routine(data)");

    with empty messaging_routine message as,

    function messaging_routine(data) {

    }

    ----

    I check using task manager to see the mem consumption on iexplore.exe (v7). The memory is slowly leaking from 71k to 79k in about 15min and it keeps going up. Anyone have any idea?

    #2
    That's not really a good test for a memory leak. IE and other browsers will pool certain objects and/or not bother to collect garbage until other actions occur (like new network traffic or new widgets being drawn) or until the browser as a whole hits certain resource limits. It's difficult to do an authoritative test for a leak without deep knowledge of the internals of IE and appropriate instrumentation hooks. Anecdotally, several SmartClient applications built with the Messaging module run all day long without leaking enough memory to impact performance.

    Comment


      #3
      I know. But I am not trying to benchmark. I just notice that both ie (7.0.5730) and firefox (3.0.1) are running extremely slow after using the app with messaging on for a while. It went up in mem to 400k+ without gc. It must be something wrong. After I turn off the messaging, my application can stay up all day too.. :) I don't know what is going on.. need to debug more...

      Comment


        #4
        Also,

        looking at the activemq admin, consumer keeps going up by 1 every 2 min. Strange...

        Comment


          #5
          SmartClient re-establishes the connection every 2 minutes (configurable) because intervening firewalls and proxies will typically sever the connection. If ActiveMQ is somehow keeping that connection open that might explain leaks.

          Another testing technique is to disable messaging but fire the exact stream of callbacks received in a real session with messaging enabled. This allows you to test for application leaks in the code that responds to messages.

          Comment


            #6
            The messaging problem that described in this thread

            http://forums.smartclient.com/showthread.php?t=1135&highlight=messaging

            look exactly like mine. And I am using 6.5 build.

            Is this bug in 6.5?

            Comment


              #7
              No, look at the dates, that message is from 2007. Both 6.5 releases are from 2008 and already contain that fix.

              Comment


                #8
                It seems like the connection is still kept opened for every 2 min (reconnect). In a hour, I will have 30 open connections. Is this a ActiveMQ configuration issue? or SmartClient server is not killing the consumer threads during the reconnect?


                In addition, if I have 3 browser client, I should see 3 consumers, right? If I unscribe at unload, it should drop back to 0. However, in my test, only 1 connection is dropped, the 2 consumers still open. hum....

                Comment


                  #9
                  Actually there was a post-6.5.1 change in how reconnects were handled server-side that might help you (you can download it here). It was believed to be a workaround for an obscure WebLogic bug but maybe it applies to your usage too - worth a shot.

                  Comment


                    #10
                    Thanks for the suggestion but 7 beta still have that bug...

                    I tried a simple case for 6.5.1 and 7 beta like

                    Code:
                    isc.Page.setEvent("load", function () {
                      Messaging.subscribe("test1Channel", "alert(data)");
                      Messaging.subscribe("test2Channel", "alert(data)");
                    });
                    
                    isc.Page.setEvent("unload", function () {
                      Messaging.unsubscribe("test1Channel");
                      Messaging.unsubscribe("test2Channel");
                    });
                    only 1 channel got disconnected during unload.

                    Comment


                      #11
                      That's again not really a valid test. Browsers do not guarantee that code called from "unload" completes normally, it can get cut off. Do you see this if you unsubscribe normally then navigate away some time later? Do you see it once the browser is completely closed and some time has passed (whatever time period ActiveMQ may require to timeout?)

                      Comment


                        #12
                        Where do you recommend to place the unscribe code instead of unload?
                        I wait for about 30 min and the connection still there...

                        In any case, I am using the amq.js from activemq now and I did not see this issue so far.

                        Comment


                          #13
                          It's not that you shouldn't try to disconnect from the "unload" event, it's just that you should be aware that it probably won't consistently happen. However, waiting 30 minutes is more than long enough.

                          Is there any way you can package up your JMS code for ActiveMQ as a test case? Whether a fix to ActiveMQ or SmartClient is required, we'd like to get this issue addressed.

                          Comment

                          Working...
                          X