[jira] [Commented] (AMQ-4182) Memory Leak for ActiveMQBytesMessage with Compression as true

["Jeff Huang (JIRA)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/AMQ-4182?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13506175#comment-13506175 ] 

Jeff Huang commented on AMQ-4182:
---------------------------------

I read the changes. Fix in reset() is good I believe. But I am worried about the finalize() method because I don't think it would work as good as we would expect. Please take a look at how Sun's JDK 1.6 implemented java.util.zip.Inflater

336     /**
337      * Closes the decompressor and discards any unprocessed input.
338      * This method should be called when the decompressor is no longer
339      * being used, but will also be called automatically by the finalize()
340      * method. Once this method is called, the behavior of the Inflater
341      * object is undefined.
342      */
343     public void end() {
344         synchronized (zsRef) {
345             long addr = zsRef.address();
346             zsRef.clear();
347             if (addr != 0) {
348                 end(addr);
349                 buf = null;
350             }
351         }
352     }
353
354     /**
355      * Closes the decompressor when garbage is collected.
356      */
357     protected void finalize() {
358         end();
359     }

They have already done finalize() with end(). So if finalize() works well, the problem wouldn't exist in the first place. And since those memory is allocated out of JVM heap, the GC could have problem to sense the necessity to clean something even the system blows out.
                
> Memory Leak for ActiveMQBytesMessage with Compression as true
> -------------------------------------------------------------
>
>                 Key: AMQ-4182
>                 URL: https://issues.apache.org/jira/browse/AMQ-4182
>             Project: ActiveMQ
>          Issue Type: Bug
>          Components: JMS client
>    Affects Versions: 5.5.1
>         Environment: Linux(Redhat 5.5), Windows 7
>            Reporter: Jeff Huang
>
> InflaterInputStream is supposed to close explicitly to release resource allocated by its JNI methods. In ActiveMQBytesMessage, dataIn property is disposed simply without closing it, which results in some weird memory leak that can't be detected from heap size. It can't be controlled by -Xmx or -XX:MaxDirectMemorySize.
> Please run the following test program to verify the issue:
> import java.util.concurrent.TimeUnit;
> import javax.jms.BytesMessage;
> import javax.jms.Connection;
> import javax.jms.Session;
> import org.apache.activemq.ActiveMQConnectionFactory;
> import org.apache.activemq.command.ActiveMQBytesMessage;
> /**
>  * A simple test to verify memory leak in ActiveMQBytesMessage.
>  */
> public class Main
> {
>     public static void main(String[] args) throws Exception 
>     {
>         ActiveMQConnectionFactory connFactory = new ActiveMQConnectionFactory("vm://localhost");
>         connFactory.setUseCompression(true);
>         Connection conn = connFactory.createConnection();
>         Session session = conn.createSession(false, Session.AUTO_ACKNOWLEDGE);
>         BytesMessage message = session.createBytesMessage();
>         
>         message.writeBytes(new byte[1024]);
>         ActiveMQBytesMessage m = (ActiveMQBytesMessage)message;
>         if(!m.isCompressed())
>         {
>             throw new RuntimeException();
>         }
>         
>         
>         while (true)
>         {
>             for (int k = 0; k < 1024; ++k)
>             {
>                 message.reset();
>                 byte[] data = new byte[1024];
>                 message.readBytes(data);
>             }
>             TimeUnit.MILLISECONDS.sleep(10);
>         }
>     }
> }

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira