|
»
»
[jira] Created: (ESPER-404) Statement resources not cleaned up after statement destroy
|
View:
New views
13 Messages
—
Rating Filter:
Alert me
|
 |
[jira] Created: (ESPER-404) Statement resources not cleaned up after statement destroy
by JIRA jira@codehaus.org
::
Rate this Message:
Statement resources not cleaned up after statement destroy
---------------------------------------------------------- Key: ESPER-404 URL: http://jira.codehaus.org/browse/ESPER-404 Project: Esper Issue Type: Bug Components: Core Affects Versions: 3.2 Environment: winxp jdk1.6 Reporter: Frederic Attachments: EsperTest-profile.png, EsperTest.java I notice quite a lot of leak with the objects defined within the statements of my application. To nail it down, I have tried with a very simple example (sending 20K times an object and being notified back on a defined statement (Select * from MyEvent)). The listing is attached in the email. Once the 20K notifications completed and the initial statement destroyed, I can still see on the profiler 1 instance of a "MyEvent" retained by StatementResultImpl (see image attached). Since the EPStatement.destory() javadoc states that "Destroy the statement releasing all statement resources.", I would have expected that nothing anymore would keep an allocation on any of MyEvent object. Is that the desirable behavior? Thanks Frédéric -- 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 |
|
|
[jira] Updated: (ESPER-404) Statement resources not cleaned up after statement destroy
by JIRA jira@codehaus.org
::
Rate this Message:
[ http://jira.codehaus.org/browse/ESPER-404?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Thomas Bernhardt updated ESPER-404: ----------------------------------- Priority: Minor (was: Major) Changed to minor. > Statement resources not cleaned up after statement destroy > ---------------------------------------------------------- > > Key: ESPER-404 > URL: http://jira.codehaus.org/browse/ESPER-404 > Project: Esper > Issue Type: Bug > Components: Core > Affects Versions: 3.2 > Environment: winxp jdk1.6 > Reporter: Frederic > Priority: Minor > Fix For: 4.0 - requires JDK6 > > Attachments: EsperTest-profile.png, EsperTest.java > > > I notice quite a lot of leak with the objects defined within the statements of my application. To nail it down, I have tried with a very simple example (sending 20K times an object and being notified back on a defined statement (Select * from MyEvent)). The listing is attached in the email. > Once the 20K notifications completed and the initial statement destroyed, I can still see on the profiler 1 instance of a "MyEvent" retained by StatementResultImpl (see image attached). Since the EPStatement.destory() javadoc states that "Destroy the statement releasing all statement resources.", I would have expected that nothing anymore would keep an allocation on any of MyEvent object. > Is that the desirable behavior? > Thanks > Frédéric -- 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 |
|
|
[jira] Updated: (ESPER-404) Statement resources not cleaned up after statement destroy
by JIRA jira@codehaus.org
::
Rate this Message:
[ http://jira.codehaus.org/browse/ESPER-404?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Thomas Bernhardt updated ESPER-404: ----------------------------------- Fix Version/s: 4.0 - requires JDK6 scheduled for 4.0 > Statement resources not cleaned up after statement destroy > ---------------------------------------------------------- > > Key: ESPER-404 > URL: http://jira.codehaus.org/browse/ESPER-404 > Project: Esper > Issue Type: Bug > Components: Core > Affects Versions: 3.2 > Environment: winxp jdk1.6 > Reporter: Frederic > Priority: Minor > Fix For: 4.0 - requires JDK6 > > Attachments: EsperTest-profile.png, EsperTest.java > > > I notice quite a lot of leak with the objects defined within the statements of my application. To nail it down, I have tried with a very simple example (sending 20K times an object and being notified back on a defined statement (Select * from MyEvent)). The listing is attached in the email. > Once the 20K notifications completed and the initial statement destroyed, I can still see on the profiler 1 instance of a "MyEvent" retained by StatementResultImpl (see image attached). Since the EPStatement.destory() javadoc states that "Destroy the statement releasing all statement resources.", I would have expected that nothing anymore would keep an allocation on any of MyEvent object. > Is that the desirable behavior? > Thanks > Frédéric -- 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 |
|
|
[jira] Updated: (ESPER-404) Statement resources not cleaned up after statement destroy keeping last event
by JIRA jira@codehaus.org
::
Rate this Message:
[ http://jira.codehaus.org/browse/ESPER-404?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Thomas Bernhardt updated ESPER-404: ----------------------------------- Summary: Statement resources not cleaned up after statement destroy keeping last event (was: Statement resources not cleaned up after statement destroy) > Statement resources not cleaned up after statement destroy keeping last event > ----------------------------------------------------------------------------- > > Key: ESPER-404 > URL: http://jira.codehaus.org/browse/ESPER-404 > Project: Esper > Issue Type: Bug > Components: Core > Affects Versions: 3.2 > Environment: winxp jdk1.6 > Reporter: Frederic > Priority: Minor > Fix For: 4.0 - requires JDK6 > > Attachments: EsperTest-profile.png, EsperTest.java > > > I notice quite a lot of leak with the objects defined within the statements of my application. To nail it down, I have tried with a very simple example (sending 20K times an object and being notified back on a defined statement (Select * from MyEvent)). The listing is attached in the email. > Once the 20K notifications completed and the initial statement destroyed, I can still see on the profiler 1 instance of a "MyEvent" retained by StatementResultImpl (see image attached). Since the EPStatement.destory() javadoc states that "Destroy the statement releasing all statement resources.", I would have expected that nothing anymore would keep an allocation on any of MyEvent object. > Is that the desirable behavior? > Thanks > Frédéric -- 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 |
|
|
[jira] Commented: (ESPER-404) Statement resources not cleaned up after statement destroy keeping last event
by JIRA jira@codehaus.org
::
Rate this Message:
[ http://jira.codehaus.org/browse/ESPER-404?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=194556#action_194556 ] Frederic commented on ESPER-404: -------------------------------- Now this minor leak sorted out, my usage of Esper unfortunately exploit it in an awkward way, causing the leak to explode. I don't know if that should be referred as another ticket, but it shows a bit criticality perspective on both ESPER-404 and ESPER-405. As you can see in the example *EqualsStatementLoadTest.java* attached above, I have an application for which sessions register and destroy many time staments (using preparedstatement: {{select * from MyEvent(Equality.eq(key, ?))}}. Since Esper does not yet support inheritance when filtering on equaled objects, the statements is made against a custom method defined in *equality.java* also attached (that's where this ticket meets ESPER-405). When I run a scenario which does 20K times the register of a new statement, the trigger of the listener against the sent event and the destroy of the statement, I end up with a "random" instances of leaking events as identified previously in the ticket (see EqualsStatementLoadTest.png attached). If the statement would not use a custom method to filter equality of the object but instead use a normal Esper = filteing {{select * from MyEvent(key = ?)}}, only one instance of the MyEvent would remain at the end (which is a more acceptable leak...) > Statement resources not cleaned up after statement destroy keeping last event > ----------------------------------------------------------------------------- > > Key: ESPER-404 > URL: http://jira.codehaus.org/browse/ESPER-404 > Project: Esper > Issue Type: Bug > Components: Core > Affects Versions: 3.2 > Environment: winxp jdk1.6 > Reporter: Frederic > Priority: Minor > Fix For: 4.0 - requires JDK6 > > Attachments: EqualsStatementLoadTest.java, EsperTest-profile.png, EsperTest.java > > > I notice quite a lot of leak with the objects defined within the statements of my application. To nail it down, I have tried with a very simple example (sending 20K times an object and being notified back on a defined statement (Select * from MyEvent)). The listing is attached in the email. > Once the 20K notifications completed and the initial statement destroyed, I can still see on the profiler 1 instance of a "MyEvent" retained by StatementResultImpl (see image attached). Since the EPStatement.destory() javadoc states that "Destroy the statement releasing all statement resources.", I would have expected that nothing anymore would keep an allocation on any of MyEvent object. > Is that the desirable behavior? > Thanks > Frédéric -- 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 |
|
|
[jira] Updated: (ESPER-404) Statement resources not cleaned up after statement destroy keeping last event
by JIRA jira@codehaus.org
::
Rate this Message:
[ http://jira.codehaus.org/browse/ESPER-404?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Frederic updated ESPER-404: --------------------------- Attachment: EqualsStatementLoadTest.java > Statement resources not cleaned up after statement destroy keeping last event > ----------------------------------------------------------------------------- > > Key: ESPER-404 > URL: http://jira.codehaus.org/browse/ESPER-404 > Project: Esper > Issue Type: Bug > Components: Core > Affects Versions: 3.2 > Environment: winxp jdk1.6 > Reporter: Frederic > Priority: Minor > Fix For: 4.0 - requires JDK6 > > Attachments: EqualsStatementLoadTest.java, EsperTest-profile.png, EsperTest.java > > > I notice quite a lot of leak with the objects defined within the statements of my application. To nail it down, I have tried with a very simple example (sending 20K times an object and being notified back on a defined statement (Select * from MyEvent)). The listing is attached in the email. > Once the 20K notifications completed and the initial statement destroyed, I can still see on the profiler 1 instance of a "MyEvent" retained by StatementResultImpl (see image attached). Since the EPStatement.destory() javadoc states that "Destroy the statement releasing all statement resources.", I would have expected that nothing anymore would keep an allocation on any of MyEvent object. > Is that the desirable behavior? > Thanks > Frédéric -- 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 |
|
|
[jira] Updated: (ESPER-404) Statement resources not cleaned up after statement destroy keeping last event
by JIRA jira@codehaus.org
::
Rate this Message:
[ http://jira.codehaus.org/browse/ESPER-404?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Frederic updated ESPER-404: --------------------------- Attachment: EqualsStatementLoadTest.png > Statement resources not cleaned up after statement destroy keeping last event > ----------------------------------------------------------------------------- > > Key: ESPER-404 > URL: http://jira.codehaus.org/browse/ESPER-404 > Project: Esper > Issue Type: Bug > Components: Core > Affects Versions: 3.2 > Environment: winxp jdk1.6 > Reporter: Frederic > Priority: Minor > Fix For: 4.0 - requires JDK6 > > Attachments: EqualsStatementLoadTest.java, EqualsStatementLoadTest.png, EsperTest-profile.png, EsperTest.java > > > I notice quite a lot of leak with the objects defined within the statements of my application. To nail it down, I have tried with a very simple example (sending 20K times an object and being notified back on a defined statement (Select * from MyEvent)). The listing is attached in the email. > Once the 20K notifications completed and the initial statement destroyed, I can still see on the profiler 1 instance of a "MyEvent" retained by StatementResultImpl (see image attached). Since the EPStatement.destory() javadoc states that "Destroy the statement releasing all statement resources.", I would have expected that nothing anymore would keep an allocation on any of MyEvent object. > Is that the desirable behavior? > Thanks > Frédéric -- 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 |
|
|
[jira] Issue Comment Edited: (ESPER-404) Statement resources not cleaned up after statement destroy keeping last event
by JIRA jira@codehaus.org
::
Rate this Message:
[ http://jira.codehaus.org/browse/ESPER-404?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=194556#action_194556 ] Frederic edited comment on ESPER-404 at 10/13/09 10:16 AM: ----------------------------------------------------------- Now this minor leak sorted out, my usage of Esper unfortunately exploit it in an awkward way, causing the leak to explode. I don't know if that should be referred as another ticket, but it shows a bit criticality perspective on both ESPER-404 and ESPER-405. As you can see in the example *EqualsStatementLoadTest.java* attached above, I have an application for which sessions register and destroy many time staments (using preparedstatement: {{select * from MyEvent(Equality.eq(key, ?))}}. Since Esper does not yet support inheritance when filtering on equaled objects, the statements is made against a custom method defined in *equality.java* also attached (that's where this ticket meets ESPER-405). When I run a scenario which does 20K times the register of a new statement, the trigger of the listener against the sent event and the destroy of the statement, I end up with a "random" instances of leaking events as identified previously in the ticket (see *EqualsStatementLoadTest.png* attached). If the statement would not use a custom method to filter equality of the object but instead use a normal Esper = filtering {{select * from MyEvent(key = ?)}}, only one instance of the MyEvent would remain at the end (which is a more acceptable leak...) was (Author: frederic.tardif): Now this minor leak sorted out, my usage of Esper unfortunately exploit it in an awkward way, causing the leak to explode. I don't know if that should be referred as another ticket, but it shows a bit criticality perspective on both ESPER-404 and ESPER-405. As you can see in the example *EqualsStatementLoadTest.java* attached above, I have an application for which sessions register and destroy many time staments (using preparedstatement: {{select * from MyEvent(Equality.eq(key, ?))}}. Since Esper does not yet support inheritance when filtering on equaled objects, the statements is made against a custom method defined in *equality.java* also attached (that's where this ticket meets ESPER-405). When I run a scenario which does 20K times the register of a new statement, the trigger of the listener against the sent event and the destroy of the statement, I end up with a "random" instances of leaking events as identified previously in the ticket (see EqualsStatementLoadTest.png attached). If the statement would not use a custom method to filter equality of the object but instead use a normal Esper = filteing {{select * from MyEvent(key = ?)}}, only one instance of the MyEvent would remain at the end (which is a more acceptable leak...) > Statement resources not cleaned up after statement destroy keeping last event > ----------------------------------------------------------------------------- > > Key: ESPER-404 > URL: http://jira.codehaus.org/browse/ESPER-404 > Project: Esper > Issue Type: Bug > Components: Core > Affects Versions: 3.2 > Environment: winxp jdk1.6 > Reporter: Frederic > Priority: Minor > Fix For: 4.0 - requires JDK6 > > Attachments: EqualsStatementLoadTest.java, EqualsStatementLoadTest.png, EsperTest-profile.png, EsperTest.java > > > I notice quite a lot of leak with the objects defined within the statements of my application. To nail it down, I have tried with a very simple example (sending 20K times an object and being notified back on a defined statement (Select * from MyEvent)). The listing is attached in the email. > Once the 20K notifications completed and the initial statement destroyed, I can still see on the profiler 1 instance of a "MyEvent" retained by StatementResultImpl (see image attached). Since the EPStatement.destory() javadoc states that "Destroy the statement releasing all statement resources.", I would have expected that nothing anymore would keep an allocation on any of MyEvent object. > Is that the desirable behavior? > Thanks > Frédéric -- 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 |
|
|
[jira] Issue Comment Edited: (ESPER-404) Statement resources not cleaned up after statement destroy keeping last event
by JIRA jira@codehaus.org
::
Rate this Message:
[ http://jira.codehaus.org/browse/ESPER-404?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=194556#action_194556 ] Frederic edited comment on ESPER-404 at 10/13/09 10:17 AM: ----------------------------------------------------------- Now this minor leak sorted out, my usage of Esper unfortunately exploit it in an awkward way, causing the leak to explode. I don't know if that should be referred as another ticket, but it shows a bit criticality perspective on both ESPER-404 and ESPER-405. As you can see in the example *EqualsStatementLoadTest.java* attached above, I have an application for which sessions register and destroy many time statements (using preparedstatement: {{select * from MyEvent(Equality.eq(key, ?))}}. Since Esper does not yet support inheritance when filtering on equaled objects, the statements is made against a custom method defined in *equality.java* also attached (that's where this ticket meets ESPER-405). When I run a scenario which does 20K times the register of a new statement, the trigger of the listener against the sent event and the destroy of the statement, I end up with a "random" instances of leaking events as identified previously in the ticket (see *EqualsStatementLoadTest.png* attached). If the statement would not use a custom method to filter equality of the object but instead use a normal Esper = filtering {{select * from MyEvent(key = ?)}}, only one instance of the MyEvent would remain at the end (which is a more acceptable leak...) was (Author: frederic.tardif): Now this minor leak sorted out, my usage of Esper unfortunately exploit it in an awkward way, causing the leak to explode. I don't know if that should be referred as another ticket, but it shows a bit criticality perspective on both ESPER-404 and ESPER-405. As you can see in the example *EqualsStatementLoadTest.java* attached above, I have an application for which sessions register and destroy many time staments (using preparedstatement: {{select * from MyEvent(Equality.eq(key, ?))}}. Since Esper does not yet support inheritance when filtering on equaled objects, the statements is made against a custom method defined in *equality.java* also attached (that's where this ticket meets ESPER-405). When I run a scenario which does 20K times the register of a new statement, the trigger of the listener against the sent event and the destroy of the statement, I end up with a "random" instances of leaking events as identified previously in the ticket (see *EqualsStatementLoadTest.png* attached). If the statement would not use a custom method to filter equality of the object but instead use a normal Esper = filtering {{select * from MyEvent(key = ?)}}, only one instance of the MyEvent would remain at the end (which is a more acceptable leak...) > Statement resources not cleaned up after statement destroy keeping last event > ----------------------------------------------------------------------------- > > Key: ESPER-404 > URL: http://jira.codehaus.org/browse/ESPER-404 > Project: Esper > Issue Type: Bug > Components: Core > Affects Versions: 3.2 > Environment: winxp jdk1.6 > Reporter: Frederic > Priority: Minor > Fix For: 4.0 - requires JDK6 > > Attachments: EqualsStatementLoadTest.java, EqualsStatementLoadTest.png, EsperTest-profile.png, EsperTest.java > > > I notice quite a lot of leak with the objects defined within the statements of my application. To nail it down, I have tried with a very simple example (sending 20K times an object and being notified back on a defined statement (Select * from MyEvent)). The listing is attached in the email. > Once the 20K notifications completed and the initial statement destroyed, I can still see on the profiler 1 instance of a "MyEvent" retained by StatementResultImpl (see image attached). Since the EPStatement.destory() javadoc states that "Destroy the statement releasing all statement resources.", I would have expected that nothing anymore would keep an allocation on any of MyEvent object. > Is that the desirable behavior? > Thanks > Frédéric -- 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 |
|
|
[jira] Issue Comment Edited: (ESPER-404) Statement resources not cleaned up after statement destroy keeping last event
by JIRA jira@codehaus.org
::
Rate this Message:
[ http://jira.codehaus.org/browse/ESPER-404?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=194556#action_194556 ] Frederic edited comment on ESPER-404 at 10/13/09 10:18 AM: ----------------------------------------------------------- Now this minor leak sorted out, my usage of Esper unfortunately exploit it in an awkward way, causing the leak to explode. I don't know if that should be referred as another ticket, but it shows a bit criticality perspective on both ESPER-404 and ESPER-405. As you can see in the example *EqualsStatementLoadTest.java* attached above, I have an application for which sessions register and destroy many time statements (using preparedstatement: [{{select * from MyEvent(Equality.eq(key, ?))}}]. Since Esper does not yet support inheritance when filtering on equaled objects, the statements is made against a custom method defined in *equality.java* also attached (that's where this ticket meets ESPER-405). When I run a scenario which does 20K times the register of a new statement, the trigger of the listener against the sent event and the destroy of the statement, I end up with a "random" instances of leaking events as identified previously in the ticket (see *EqualsStatementLoadTest.png* attached). If the statement would not use a custom method to filter equality of the object but instead use a normal Esper = filtering [{{select * from MyEvent(key = ?)}}], only one instance of the MyEvent would remain at the end (which is a more acceptable leak...) was (Author: frederic.tardif): Now this minor leak sorted out, my usage of Esper unfortunately exploit it in an awkward way, causing the leak to explode. I don't know if that should be referred as another ticket, but it shows a bit criticality perspective on both ESPER-404 and ESPER-405. As you can see in the example *EqualsStatementLoadTest.java* attached above, I have an application for which sessions register and destroy many time statements (using preparedstatement: {{select * from MyEvent(Equality.eq(key, ?))}}. Since Esper does not yet support inheritance when filtering on equaled objects, the statements is made against a custom method defined in *equality.java* also attached (that's where this ticket meets ESPER-405). When I run a scenario which does 20K times the register of a new statement, the trigger of the listener against the sent event and the destroy of the statement, I end up with a "random" instances of leaking events as identified previously in the ticket (see *EqualsStatementLoadTest.png* attached). If the statement would not use a custom method to filter equality of the object but instead use a normal Esper = filtering {{select * from MyEvent(key = ?)}}, only one instance of the MyEvent would remain at the end (which is a more acceptable leak...) > Statement resources not cleaned up after statement destroy keeping last event > ----------------------------------------------------------------------------- > > Key: ESPER-404 > URL: http://jira.codehaus.org/browse/ESPER-404 > Project: Esper > Issue Type: Bug > Components: Core > Affects Versions: 3.2 > Environment: winxp jdk1.6 > Reporter: Frederic > Priority: Minor > Fix For: 4.0 - requires JDK6 > > Attachments: EqualsStatementLoadTest.java, EqualsStatementLoadTest.png, EsperTest-profile.png, EsperTest.java > > > I notice quite a lot of leak with the objects defined within the statements of my application. To nail it down, I have tried with a very simple example (sending 20K times an object and being notified back on a defined statement (Select * from MyEvent)). The listing is attached in the email. > Once the 20K notifications completed and the initial statement destroyed, I can still see on the profiler 1 instance of a "MyEvent" retained by StatementResultImpl (see image attached). Since the EPStatement.destory() javadoc states that "Destroy the statement releasing all statement resources.", I would have expected that nothing anymore would keep an allocation on any of MyEvent object. > Is that the desirable behavior? > Thanks > Frédéric -- 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 |
|
|
[jira] Issue Comment Edited: (ESPER-404) Statement resources not cleaned up after statement destroy keeping last event
by JIRA jira@codehaus.org
::
Rate this Message:
[ http://jira.codehaus.org/browse/ESPER-404?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=194556#action_194556 ] Frederic edited comment on ESPER-404 at 10/13/09 10:20 AM: ----------------------------------------------------------- Now this minor leak sorted out, my usage of Esper unfortunately exploit it in an awkward way, causing the leak to explode. I don't know if that should be referred as another ticket, but it shows a bit criticality perspective on both ESPER-404 and ESPER-405. As you can see in the example *EqualsStatementLoadTest.java* attached above, I have an application for which sessions register and destroy many time statements (using preparedstatement: {{[select * from MyEvent(Equality.eq(key, ?))]}}. Since Esper does not yet support inheritance when filtering on equaled objects, the statements are made against a custom eq(obj1, obj2) method defined in *equality.java* also attached (that's where this ticket meets ESPER-405). When I run a scenario which does 20K times the register of a new statement, the trigger of the listener against the sent event and the destroy of the statement, I end up with a "random" instances of leaking events as identified previously in the ticket (see *EqualsStatementLoadTest.png* attached). If the statement would not use a custom method to filter equality of the object but instead use a normal Esper = filtering {{[select * from MyEvent(key = ?)]}}, only one instance of the MyEvent would remain at the end (which is a more acceptable leak...) was (Author: frederic.tardif): Now this minor leak sorted out, my usage of Esper unfortunately exploit it in an awkward way, causing the leak to explode. I don't know if that should be referred as another ticket, but it shows a bit criticality perspective on both ESPER-404 and ESPER-405. As you can see in the example *EqualsStatementLoadTest.java* attached above, I have an application for which sessions register and destroy many time statements (using preparedstatement: [{{select * from MyEvent(Equality.eq(key, ?))}}]. Since Esper does not yet support inheritance when filtering on equaled objects, the statements is made against a custom method defined in *equality.java* also attached (that's where this ticket meets ESPER-405). When I run a scenario which does 20K times the register of a new statement, the trigger of the listener against the sent event and the destroy of the statement, I end up with a "random" instances of leaking events as identified previously in the ticket (see *EqualsStatementLoadTest.png* attached). If the statement would not use a custom method to filter equality of the object but instead use a normal Esper = filtering [{{select * from MyEvent(key = ?)}}], only one instance of the MyEvent would remain at the end (which is a more acceptable leak...) > Statement resources not cleaned up after statement destroy keeping last event > ----------------------------------------------------------------------------- > > Key: ESPER-404 > URL: http://jira.codehaus.org/browse/ESPER-404 > Project: Esper > Issue Type: Bug > Components: Core > Affects Versions: 3.2 > Environment: winxp jdk1.6 > Reporter: Frederic > Priority: Minor > Fix For: 4.0 - requires JDK6 > > Attachments: EqualsStatementLoadTest.java, EqualsStatementLoadTest.png, EsperTest-profile.png, EsperTest.java > > > I notice quite a lot of leak with the objects defined within the statements of my application. To nail it down, I have tried with a very simple example (sending 20K times an object and being notified back on a defined statement (Select * from MyEvent)). The listing is attached in the email. > Once the 20K notifications completed and the initial statement destroyed, I can still see on the profiler 1 instance of a "MyEvent" retained by StatementResultImpl (see image attached). Since the EPStatement.destory() javadoc states that "Destroy the statement releasing all statement resources.", I would have expected that nothing anymore would keep an allocation on any of MyEvent object. > Is that the desirable behavior? > Thanks > Frédéric -- 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 |
|
|
[jira] Updated: (ESPER-404) Statement resources not cleaned up after statement destroy keeping last event
by JIRA jira@codehaus.org
::
Rate this Message:
[ http://jira.codehaus.org/browse/ESPER-404?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Frederic updated ESPER-404: --------------------------- Attachment: Equality.java > Statement resources not cleaned up after statement destroy keeping last event > ----------------------------------------------------------------------------- > > Key: ESPER-404 > URL: http://jira.codehaus.org/browse/ESPER-404 > Project: Esper > Issue Type: Bug > Components: Core > Affects Versions: 3.2 > Environment: winxp jdk1.6 > Reporter: Frederic > Priority: Minor > Fix For: 4.0 - requires JDK6 > > Attachments: Equality.java, EqualsStatementLoadTest.java, EqualsStatementLoadTest.png, EsperTest-profile.png, EsperTest.java > > > I notice quite a lot of leak with the objects defined within the statements of my application. To nail it down, I have tried with a very simple example (sending 20K times an object and being notified back on a defined statement (Select * from MyEvent)). The listing is attached in the email. > Once the 20K notifications completed and the initial statement destroyed, I can still see on the profiler 1 instance of a "MyEvent" retained by StatementResultImpl (see image attached). Since the EPStatement.destory() javadoc states that "Destroy the statement releasing all statement resources.", I would have expected that nothing anymore would keep an allocation on any of MyEvent object. > Is that the desirable behavior? > Thanks > Frédéric -- 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 |
|
|
[jira] Resolved: (ESPER-404) Statement resources not cleaned up after statement destroy keeping last event
by JIRA jira@codehaus.org
::
Rate this Message:
[ http://jira.codehaus.org/browse/ESPER-404?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Thomas Bernhardt resolved ESPER-404. ------------------------------------ Resolution: Fixed Fix Version/s: (was: 4.0 - requires JDK6) 3.3 Assigned to 3.3 release, in branch enhancements330 > Statement resources not cleaned up after statement destroy keeping last event > ----------------------------------------------------------------------------- > > Key: ESPER-404 > URL: http://jira.codehaus.org/browse/ESPER-404 > 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: Equality.java, EqualsStatementLoadTest.java, EqualsStatementLoadTest.png, EsperTest-profile.png, EsperTest.java > > > I notice quite a lot of leak with the objects defined within the statements of my application. To nail it down, I have tried with a very simple example (sending 20K times an object and being notified back on a defined statement (Select * from MyEvent)). The listing is attached in the email. > Once the 20K notifications completed and the initial statement destroyed, I can still see on the profiler 1 instance of a "MyEvent" retained by StatementResultImpl (see image attached). Since the EPStatement.destory() javadoc states that "Destroy the statement releasing all statement resources.", I would have expected that nothing anymore would keep an allocation on any of MyEvent object. > Is that the desirable behavior? > Thanks > Frédéric -- 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 |
| Free embeddable forum powered by Nabble | Forum Help |
