You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@geronimo.apache.org by "Kevan Miller (JIRA)" <de...@geronimo.apache.org> on 2005/11/10 22:36:02 UTC
[jira] Created: (GERONIMO-1155) ActiveMQSessions build up during DayTrader execution
ActiveMQSessions build up during DayTrader execution
----------------------------------------------------
Key: GERONIMO-1155
URL: http://issues.apache.org/jira/browse/GERONIMO-1155
Project: Geronimo
Type: Bug
Components: ActiveMQ
Versions: 1.0-M5
Environment: Suse / JDK 1.4
Reporter: Kevan Miller
Fix For: 1.0
While running DayTrader, the server got an OutOfMemoryException. At the time of failure, there were over 17,000 ActiveMQSession instances registered with an ActiveMQ TransactionContext. I believe that Sessions are being registered with the ActiveMQManagedConnection TransactionContext, but will never be unregistered via TransactionContext.removeSession(Session).
In a standalone environment, the TransactionContext is owned by the Session. So, a Session does not need to be removed from the TransactionContext. Their lifetimes are the same.
In a ManagedConnection environment, a TransactionContext is created for the ActiveMQManagedConnection. An RATransactionContext is generated for each new Session. This RATransactionContext will proxy any Session registrations to the ManagedConnection TransactionContext. So, each new Session will be registered with the ManagedConnection TransactionContext, but never removed.
The above is from my reading of the code. I don't currently have an environment where I can directly test this. Hope to have some empirical results, tomorrow.
The obvious fix is to add the following to ActiveMQSession.doClose():
this.transactionContext.removeSession(this);
I'll post a patch. Let me know if I'm missing something...
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
[jira] Updated: (GERONIMO-1155) ActiveMQSessions build up during DayTrader execution
Posted by "Kevan Miller (JIRA)" <de...@geronimo.apache.org>.
[ http://issues.apache.org/jira/browse/GERONIMO-1155?page=all ]
Kevan Miller updated GERONIMO-1155:
-----------------------------------
Attachment: RemoveSession.patch
Patch was generated against 3.2.
> ActiveMQSessions build up during DayTrader execution
> ----------------------------------------------------
>
> Key: GERONIMO-1155
> URL: http://issues.apache.org/jira/browse/GERONIMO-1155
> Project: Geronimo
> Type: Bug
> Components: ActiveMQ
> Versions: 1.0-M5
> Environment: Suse / JDK 1.4
> Reporter: Kevan Miller
> Fix For: 1.0
> Attachments: RemoveSession.patch
>
> While running DayTrader, the server got an OutOfMemoryException. At the time of failure, there were over 17,000 ActiveMQSession instances registered with an ActiveMQ TransactionContext. I believe that Sessions are being registered with the ActiveMQManagedConnection TransactionContext, but will never be unregistered via TransactionContext.removeSession(Session).
> In a standalone environment, the TransactionContext is owned by the Session. So, a Session does not need to be removed from the TransactionContext. Their lifetimes are the same.
> In a ManagedConnection environment, a TransactionContext is created for the ActiveMQManagedConnection. An RATransactionContext is generated for each new Session. This RATransactionContext will proxy any Session registrations to the ManagedConnection TransactionContext. So, each new Session will be registered with the ManagedConnection TransactionContext, but never removed.
> The above is from my reading of the code. I don't currently have an environment where I can directly test this. Hope to have some empirical results, tomorrow.
> The obvious fix is to add the following to ActiveMQSession.doClose():
> this.transactionContext.removeSession(this);
> I'll post a patch. Let me know if I'm missing something...
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
[jira] Closed: (GERONIMO-1155) ActiveMQSessions build up during
DayTrader execution
Posted by "Kevan Miller (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/GERONIMO-1155?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Kevan Miller closed GERONIMO-1155.
----------------------------------
> ActiveMQSessions build up during DayTrader execution
> ----------------------------------------------------
>
> Key: GERONIMO-1155
> URL: https://issues.apache.org/jira/browse/GERONIMO-1155
> Project: Geronimo
> Issue Type: Bug
> Security Level: public(Regular issues)
> Components: ActiveMQ
> Affects Versions: 1.0-M5
> Environment: Suse / JDK 1.4
> Reporter: Kevan Miller
> Fix For: 1.0
>
> Attachments: RemoveSession.patch, RemoveSessionUnified.patch
>
>
> While running DayTrader, the server got an OutOfMemoryException. At the time of failure, there were over 17,000 ActiveMQSession instances registered with an ActiveMQ TransactionContext. I believe that Sessions are being registered with the ActiveMQManagedConnection TransactionContext, but will never be unregistered via TransactionContext.removeSession(Session).
> In a standalone environment, the TransactionContext is owned by the Session. So, a Session does not need to be removed from the TransactionContext. Their lifetimes are the same.
> In a ManagedConnection environment, a TransactionContext is created for the ActiveMQManagedConnection. An RATransactionContext is generated for each new Session. This RATransactionContext will proxy any Session registrations to the ManagedConnection TransactionContext. So, each new Session will be registered with the ManagedConnection TransactionContext, but never removed.
> The above is from my reading of the code. I don't currently have an environment where I can directly test this. Hope to have some empirical results, tomorrow.
> The obvious fix is to add the following to ActiveMQSession.doClose():
> this.transactionContext.removeSession(this);
> I'll post a patch. Let me know if I'm missing something...
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Resolved: (GERONIMO-1155) ActiveMQSessions build up during DayTrader execution
Posted by "james strachan (JIRA)" <de...@geronimo.apache.org>.
[ http://issues.apache.org/jira/browse/GERONIMO-1155?page=all ]
james strachan resolved GERONIMO-1155:
--------------------------------------
Resolution: Fixed
patch applied, thanks!
> ActiveMQSessions build up during DayTrader execution
> ----------------------------------------------------
>
> Key: GERONIMO-1155
> URL: http://issues.apache.org/jira/browse/GERONIMO-1155
> Project: Geronimo
> Type: Bug
> Components: ActiveMQ
> Versions: 1.0-M5
> Environment: Suse / JDK 1.4
> Reporter: Kevan Miller
> Fix For: 1.0
> Attachments: RemoveSession.patch, RemoveSessionUnified.patch
>
> While running DayTrader, the server got an OutOfMemoryException. At the time of failure, there were over 17,000 ActiveMQSession instances registered with an ActiveMQ TransactionContext. I believe that Sessions are being registered with the ActiveMQManagedConnection TransactionContext, but will never be unregistered via TransactionContext.removeSession(Session).
> In a standalone environment, the TransactionContext is owned by the Session. So, a Session does not need to be removed from the TransactionContext. Their lifetimes are the same.
> In a ManagedConnection environment, a TransactionContext is created for the ActiveMQManagedConnection. An RATransactionContext is generated for each new Session. This RATransactionContext will proxy any Session registrations to the ManagedConnection TransactionContext. So, each new Session will be registered with the ManagedConnection TransactionContext, but never removed.
> The above is from my reading of the code. I don't currently have an environment where I can directly test this. Hope to have some empirical results, tomorrow.
> The obvious fix is to add the following to ActiveMQSession.doClose():
> this.transactionContext.removeSession(this);
> I'll post a patch. Let me know if I'm missing something...
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
[jira] Updated: (GERONIMO-1155) ActiveMQSessions build up during DayTrader execution
Posted by "Kevan Miller (JIRA)" <de...@geronimo.apache.org>.
[ http://issues.apache.org/jira/browse/GERONIMO-1155?page=all ]
Kevan Miller updated GERONIMO-1155:
-----------------------------------
Geronimo Info: [Patch Available]
> ActiveMQSessions build up during DayTrader execution
> ----------------------------------------------------
>
> Key: GERONIMO-1155
> URL: http://issues.apache.org/jira/browse/GERONIMO-1155
> Project: Geronimo
> Type: Bug
> Components: ActiveMQ
> Versions: 1.0-M5
> Environment: Suse / JDK 1.4
> Reporter: Kevan Miller
> Fix For: 1.0
> Attachments: RemoveSession.patch
>
> While running DayTrader, the server got an OutOfMemoryException. At the time of failure, there were over 17,000 ActiveMQSession instances registered with an ActiveMQ TransactionContext. I believe that Sessions are being registered with the ActiveMQManagedConnection TransactionContext, but will never be unregistered via TransactionContext.removeSession(Session).
> In a standalone environment, the TransactionContext is owned by the Session. So, a Session does not need to be removed from the TransactionContext. Their lifetimes are the same.
> In a ManagedConnection environment, a TransactionContext is created for the ActiveMQManagedConnection. An RATransactionContext is generated for each new Session. This RATransactionContext will proxy any Session registrations to the ManagedConnection TransactionContext. So, each new Session will be registered with the ManagedConnection TransactionContext, but never removed.
> The above is from my reading of the code. I don't currently have an environment where I can directly test this. Hope to have some empirical results, tomorrow.
> The obvious fix is to add the following to ActiveMQSession.doClose():
> this.transactionContext.removeSession(this);
> I'll post a patch. Let me know if I'm missing something...
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
[jira] Updated: (GERONIMO-1155) ActiveMQSessions build up during DayTrader execution
Posted by "Kevan Miller (JIRA)" <de...@geronimo.apache.org>.
[ http://issues.apache.org/jira/browse/GERONIMO-1155?page=all ]
Kevan Miller updated GERONIMO-1155:
-----------------------------------
Attachment: RemoveSessionUnified.patch
Forgot -u on the diff...
> ActiveMQSessions build up during DayTrader execution
> ----------------------------------------------------
>
> Key: GERONIMO-1155
> URL: http://issues.apache.org/jira/browse/GERONIMO-1155
> Project: Geronimo
> Type: Bug
> Components: ActiveMQ
> Versions: 1.0-M5
> Environment: Suse / JDK 1.4
> Reporter: Kevan Miller
> Fix For: 1.0
> Attachments: RemoveSession.patch, RemoveSessionUnified.patch
>
> While running DayTrader, the server got an OutOfMemoryException. At the time of failure, there were over 17,000 ActiveMQSession instances registered with an ActiveMQ TransactionContext. I believe that Sessions are being registered with the ActiveMQManagedConnection TransactionContext, but will never be unregistered via TransactionContext.removeSession(Session).
> In a standalone environment, the TransactionContext is owned by the Session. So, a Session does not need to be removed from the TransactionContext. Their lifetimes are the same.
> In a ManagedConnection environment, a TransactionContext is created for the ActiveMQManagedConnection. An RATransactionContext is generated for each new Session. This RATransactionContext will proxy any Session registrations to the ManagedConnection TransactionContext. So, each new Session will be registered with the ManagedConnection TransactionContext, but never removed.
> The above is from my reading of the code. I don't currently have an environment where I can directly test this. Hope to have some empirical results, tomorrow.
> The obvious fix is to add the following to ActiveMQSession.doClose():
> this.transactionContext.removeSession(this);
> I'll post a patch. Let me know if I'm missing something...
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira