Announcement Announcement Module
Collapse
No announcement yet.
Spring Integration BUG -classes not GC'ed ? Page Title Module
Move Remove Collapse
X
Conversation Detail Module
Collapse
  • Filter
  • Time
  • Show
Clear All
new posts

  • Spring Integration BUG -classes not GC'ed ?

    We have done the following use case with two bundles [Source Code attached]


    Channel-OutBound

    Bundle which has a channel defined , and events are published into the channel using gateway. Spring timer task is used for periodic creation of events.


    The pub-sub channel is exposed as a OSGi service.


    2. Channel Inbound


    Imports the channel as a OSGi service


    Listens to the channel and prints the message when found.


    We Deploy the bundles in the following order – channel outbound followed by Channel Inbound


    Even after I delete the channel inbound jar, classes of inbound jar are not garbage collected, even though it does not have any reference in any other bundles


    I Have used YourKit to see that the class is not GC’ed . Also I see the print statement on the listener appearing in the trace even after I delete the channel-inbound bundle.


    Is this a BUG of am I doing any mistake here?

    Also I did a similar test, without using spring Integration but with only OSGi service and I see that the classes are properly GC’ed( again using yourkit).


    Regards,
    Sudheer Krishna

  • #2
    I am not sure what classes you are talking about (I could not unzip your files. . . they seem to be corrupted), so may be you can provide more details.
    However, I seriously doubt that this is a bug. This is how OSGi works (4.3.11):
    Code:
    Once this method (UNINSTALL) returns, the state of the OSGi Service Platform must be 
    the same as if the bundle had never been installed, unless: 
    • The uninstalled bundle has exported any packages (via its Export- 
    Package manifest header) 
    • The uninstalled bundle was selected by the Framework as the exporter of 
    these packages. 
    If none of the old exports are used, then the old exports must be removed. 
    Otherwise, all old exports must remain available for existing bundles and 
    future resolves until the refreshPackages method is called or the Frame- 
    work is restarted.
    You can get more details from the spec itself
    Cheers

    Comment


    • #3
      I have gone through the OSGi specs and its says that

      if the deleted bundles has any references then it is fair that classes do not get deleted.

      But my listener bundle(channel-bundle),does not either export any package nor service, It only imports a service.

      I have uploaded by bundle source as rar files .

      Download it and use winrar to unzip it.[rar files were not allowed for upload].

      Comment


      • #4
        i have attached the source again.

        I have used 7zip to zip the source code.

        Comment


        • #5
          Any update ?


          Am i doing any mistake ? or is it a BUG ?

          Comment


          • #6
            I haven't gat a chance to look, but my guess is that classes exposed by the Inbound were wired to the outbound when both in/outbound were available. When you uninstalled inbound, outbound still holds references to those classes.
            Try to refresh Outbound after you uninstall inbound.

            Comment


            • #7
              My inbound does not export any package at all .

              Inbound bundle only imports package and service and i see no reason for it to be not gc'ed.

              Inbound manifest

              Manifest-Version: 1.0
              Bundle-Version: 1.0.0
              Bundle-Name: Channel_outbound Bundle
              Bundle-ManifestVersion: 2
              Bundle-SymbolicName: channel_inbound
              Import-Library: org.springframework.spring.instrumented
              Import-Bundle: org.springframework.integration,org.springframewor k.integration.adapter

              Comment


              • #8
                I was using spring integration 1.0.2 SR1 , and that was the reason for this wierd behavior.

                Now i moved to spring integration 1.0.3 and spring dm 1.0.2 and everything seems to work fine .

                Thanks :-)

                Comment

                Working...
                X