[jira] Created: (ESPER-406) OutOfMemory : StatementMetrics not cleaned up after statement destroyed

OutOfMemory : StatementMetrics not cleaned up after statement destroyed
-----------------------------------------------------------------------

                 Key: ESPER-406
                 URL: http://jira.codehaus.org/browse/ESPER-406
             Project: Esper
          Issue Type: Bug
          Components: Core
    Affects Versions: 3.2
         Environment: winxp jdk1.6
            Reporter: Frederic
         Attachments: EsperTest.java, StatementMetricHandle-footprint.png

If I run a simple program (*EsperTest.java*) which loops 300K times by:
- creating a statement
- sending it
- printing the update through the listener
- destroying statement

it rapidly runs out of memory (see *StatementMetricHandle.png* memory/CPU graphs attached) with a big footprint of StatementMetricHandle.

I thought that statistics engine was turned off by default, so why is there so many Metrics handle?


--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

       

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email

     [ http://jira.codehaus.org/browse/ESPER-406?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Frederic Tardif updated ESPER-406:
----------------------------------

    Attachment: StatementMetricHandle-HeapDump.png

> OutOfMemory : StatementMetrics not cleaned up after statement destroyed
> -----------------------------------------------------------------------
>
>                 Key: ESPER-406
>                 URL: http://jira.codehaus.org/browse/ESPER-406
>             Project: Esper
>          Issue Type: Bug
>          Components: Core
>    Affects Versions: 3.2
>         Environment: winxp jdk1.6
>            Reporter: Frederic Tardif
>         Attachments: EsperTest.java, StatementMetricHandle-footprint.png, StatementMetricHandle-HeapDump.png
>
>
> If I run a simple program (*EsperTest.java*) which loops 300K times by:
> - creating a statement
> - sending it
> - printing the update through the listener
> - destroying statement
> it rapidly runs out of memory (see *StatementMetricHandle.png* memory/CPU graphs attached) with a big footprint of StatementMetricHandle.
> I thought that statistics engine was turned off by default, so why is there so many Metrics handle?

--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

       

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email

    [ http://jira.codehaus.org/browse/ESPER-406?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=194676#action_194676 ]

Thomas Bernhardt commented on ESPER-406:
----------------------------------------

Scheduled for release 4.0

> OutOfMemory : StatementMetrics not cleaned up after statement destroyed
> -----------------------------------------------------------------------
>
>                 Key: ESPER-406
>                 URL: http://jira.codehaus.org/browse/ESPER-406
>             Project: Esper
>          Issue Type: Bug
>          Components: Core
>    Affects Versions: 3.2
>         Environment: winxp jdk1.6
>            Reporter: Frederic Tardif
>            Priority: Minor
>             Fix For: 4.0 - requires JDK6
>
>         Attachments: EsperTest.java, StatementMetricHandle-footprint.png, StatementMetricHandle-HeapDump.png
>
>
> If I run a simple program (*EsperTest.java*) which loops 300K times by:
> - creating a statement
> - sending it
> - printing the update through the listener
> - destroying statement
> it rapidly runs out of memory (see *StatementMetricHandle.png* memory/CPU graphs attached) with a big footprint of StatementMetricHandle.
> I thought that statistics engine was turned off by default, so why is there so many Metrics handle?

--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

       

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email

     [ http://jira.codehaus.org/browse/ESPER-406?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Thomas Bernhardt updated ESPER-406:
-----------------------------------

         Priority: Minor  (was: Major)
    Fix Version/s: 4.0 - requires JDK6

Workaround: assign a statement name.

> OutOfMemory : StatementMetrics not cleaned up after statement destroyed
> -----------------------------------------------------------------------
>
>                 Key: ESPER-406
>                 URL: http://jira.codehaus.org/browse/ESPER-406
>             Project: Esper
>          Issue Type: Bug
>          Components: Core
>    Affects Versions: 3.2
>         Environment: winxp jdk1.6
>            Reporter: Frederic Tardif
>            Priority: Minor
>             Fix For: 4.0 - requires JDK6
>
>         Attachments: EsperTest.java, StatementMetricHandle-footprint.png, StatementMetricHandle-HeapDump.png
>
>
> If I run a simple program (*EsperTest.java*) which loops 300K times by:
> - creating a statement
> - sending it
> - printing the update through the listener
> - destroying statement
> it rapidly runs out of memory (see *StatementMetricHandle.png* memory/CPU graphs attached) with a big footprint of StatementMetricHandle.
> I thought that statistics engine was turned off by default, so why is there so many Metrics handle?

--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

       

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email

    [ http://jira.codehaus.org/browse/ESPER-406?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=194699#action_194699 ]

Frederic Tardif commented on ESPER-406:
---------------------------------------

thanks for the workaround. It seems to work.

> OutOfMemory : StatementMetrics not cleaned up after statement destroyed
> -----------------------------------------------------------------------
>
>                 Key: ESPER-406
>                 URL: http://jira.codehaus.org/browse/ESPER-406
>             Project: Esper
>          Issue Type: Bug
>          Components: Core
>    Affects Versions: 3.2
>         Environment: winxp jdk1.6
>            Reporter: Frederic Tardif
>            Priority: Minor
>             Fix For: 4.0 - requires JDK6
>
>         Attachments: EsperTest.java, StatementMetricHandle-footprint.png, StatementMetricHandle-HeapDump.png
>
>
> If I run a simple program (*EsperTest.java*) which loops 300K times by:
> - creating a statement
> - sending it
> - printing the update through the listener
> - destroying statement
> it rapidly runs out of memory (see *StatementMetricHandle.png* memory/CPU graphs attached) with a big footprint of StatementMetricHandle.
> I thought that statistics engine was turned off by default, so why is there so many Metrics handle?

--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

       

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email

     [ http://jira.codehaus.org/browse/ESPER-406?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Frederic Tardif updated ESPER-406:
----------------------------------

    Attachment: esper-406-patch.txt

unfortunately, even by assigning a statement name, StatementMetricRepository would continue to put in a map the postfix names of the created statements, still ending-up as a OutOfMemory.

Here is a patch which ensures that StatementMetrics are not computed when stated as disabled in the config

> OutOfMemory : StatementMetrics not cleaned up after statement destroyed
> -----------------------------------------------------------------------
>
>                 Key: ESPER-406
>                 URL: http://jira.codehaus.org/browse/ESPER-406
>             Project: Esper
>          Issue Type: Bug
>          Components: Core
>    Affects Versions: 3.2
>         Environment: winxp jdk1.6
>            Reporter: Frederic Tardif
>            Priority: Minor
>             Fix For: 4.0 - requires JDK6
>
>         Attachments: esper-406-patch.txt, EsperTest.java, StatementMetricHandle-footprint.png, StatementMetricHandle-HeapDump.png
>
>
> If I run a simple program (*EsperTest.java*) which loops 300K times by:
> - creating a statement
> - sending it
> - printing the update through the listener
> - destroying statement
> it rapidly runs out of memory (see *StatementMetricHandle.png* memory/CPU graphs attached) with a big footprint of StatementMetricHandle.
> I thought that statistics engine was turned off by default, so why is there so many Metrics handle?

--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

       

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email

    [ http://jira.codehaus.org/browse/ESPER-406?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=195034#action_195034 ]

Alexandre Vasseur commented on ESPER-406:
-----------------------------------------

Just a note: you are running with a 64Mb heap which is very small. As a workaround to delay the issue use a larger heap with -Xmx JVM option
There is definitely a bug here but the vast majority of use cases are not creating and destroying that many statements within a short lifetime

> OutOfMemory : StatementMetrics not cleaned up after statement destroyed
> -----------------------------------------------------------------------
>
>                 Key: ESPER-406
>                 URL: http://jira.codehaus.org/browse/ESPER-406
>             Project: Esper
>          Issue Type: Bug
>          Components: Core
>    Affects Versions: 3.2
>         Environment: winxp jdk1.6
>            Reporter: Frederic Tardif
>            Priority: Minor
>             Fix For: 4.0 - requires JDK6
>
>         Attachments: esper-406-patch.txt, EsperTest.java, StatementMetricHandle-footprint.png, StatementMetricHandle-HeapDump.png
>
>
> If I run a simple program (*EsperTest.java*) which loops 300K times by:
> - creating a statement
> - sending it
> - printing the update through the listener
> - destroying statement
> it rapidly runs out of memory (see *StatementMetricHandle.png* memory/CPU graphs attached) with a big footprint of StatementMetricHandle.
> I thought that statistics engine was turned off by default, so why is there so many Metrics handle?

--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

       

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email

    [ http://jira.codehaus.org/browse/ESPER-406?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=194901#action_194901 ]

Frederic Tardif edited comment on ESPER-406 at 10/16/09 1:46 PM:
-----------------------------------------------------------------

unfortunately, even by assigning a statement name, StatementMetricRepository would continue to put in a map the postfix names of the created statements, still ending-up as a OutOfMemory.

attached *ESPER-406-patch.txt* which ensures that StatementMetrics are not computed when stated as disabled in the config

      was (Author: frederic.tardif):
    unfortunately, even by assigning a statement name, StatementMetricRepository would continue to put in a map the postfix names of the created statements, still ending-up as a OutOfMemory.

Here is a patch which ensures that StatementMetrics are not computed when stated as disabled in the config
 

> OutOfMemory : StatementMetrics not cleaned up after statement destroyed
> -----------------------------------------------------------------------
>
>                 Key: ESPER-406
>                 URL: http://jira.codehaus.org/browse/ESPER-406
>             Project: Esper
>          Issue Type: Bug
>          Components: Core
>    Affects Versions: 3.2
>         Environment: winxp jdk1.6
>            Reporter: Frederic Tardif
>            Priority: Minor
>             Fix For: 4.0 - requires JDK6
>
>         Attachments: esper-406-patch.txt, EsperTest.java, StatementMetricHandle-footprint.png, StatementMetricHandle-HeapDump.png
>
>
> If I run a simple program (*EsperTest.java*) which loops 300K times by:
> - creating a statement
> - sending it
> - printing the update through the listener
> - destroying statement
> it rapidly runs out of memory (see *StatementMetricHandle.png* memory/CPU graphs attached) with a big footprint of StatementMetricHandle.
> I thought that statistics engine was turned off by default, so why is there so many Metrics handle?

--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

       

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email

    [ http://jira.codehaus.org/browse/ESPER-406?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=194901#action_194901 ]

Frederic Tardif edited comment on ESPER-406 at 10/16/09 1:47 PM:
-----------------------------------------------------------------

unfortunately, even by assigning a statement name, StatementMetricRepository would continue to put in a map the postfix names of the created statements, still ending-up as a OutOfMemory.

attached *esper-406-patch.txt* which ensures that StatementMetrics are not computed when stated as disabled in the config

      was (Author: frederic.tardif):
    unfortunately, even by assigning a statement name, StatementMetricRepository would continue to put in a map the postfix names of the created statements, still ending-up as a OutOfMemory.

attached *ESPER-406-patch.txt* which ensures that StatementMetrics are not computed when stated as disabled in the config
 

> OutOfMemory : StatementMetrics not cleaned up after statement destroyed
> -----------------------------------------------------------------------
>
>                 Key: ESPER-406
>                 URL: http://jira.codehaus.org/browse/ESPER-406
>             Project: Esper
>          Issue Type: Bug
>          Components: Core
>    Affects Versions: 3.2
>         Environment: winxp jdk1.6
>            Reporter: Frederic Tardif
>            Priority: Minor
>             Fix For: 4.0 - requires JDK6
>
>         Attachments: esper-406-patch.txt, EsperTest.java, StatementMetricHandle-footprint.png, StatementMetricHandle-HeapDump.png
>
>
> If I run a simple program (*EsperTest.java*) which loops 300K times by:
> - creating a statement
> - sending it
> - printing the update through the listener
> - destroying statement
> it rapidly runs out of memory (see *StatementMetricHandle.png* memory/CPU graphs attached) with a big footprint of StatementMetricHandle.
> I thought that statistics engine was turned off by default, so why is there so many Metrics handle?

--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

       

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email

     [ http://jira.codehaus.org/browse/ESPER-406?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Thomas Bernhardt resolved ESPER-406.
------------------------------------

       Resolution: Fixed
    Fix Version/s:     (was: 4.0 - requires JDK6)
                   3.3

In release 3.3

> OutOfMemory : StatementMetrics not cleaned up after statement destroyed
> -----------------------------------------------------------------------
>
>                 Key: ESPER-406
>                 URL: http://jira.codehaus.org/browse/ESPER-406
>             Project: Esper
>          Issue Type: Bug
>          Components: Core
>    Affects Versions: 3.2
>         Environment: winxp jdk1.6
>            Reporter: Frederic Tardif
>            Priority: Minor
>             Fix For: 3.3
>
>         Attachments: esper-406-patch.txt, EsperTest.java, StatementMetricHandle-footprint.png, StatementMetricHandle-HeapDump.png
>
>
> If I run a simple program (*EsperTest.java*) which loops 300K times by:
> - creating a statement
> - sending it
> - printing the update through the listener
> - destroying statement
> it rapidly runs out of memory (see *StatementMetricHandle.png* memory/CPU graphs attached) with a big footprint of StatementMetricHandle.
> I thought that statistics engine was turned off by default, so why is there so many Metrics handle?

--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

       

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email