[JBoss JIRA] (JBTM-2234) out of memory when logging more messages than heap size (surefire issue)
by Tom Jenkinson (JIRA)
[ https://issues.jboss.org/browse/JBTM-2234?page=com.atlassian.jira.plugin.... ]
Issue was automatically transitioned when Tom Jenkinson created pull request #34 in GitHub
------------------------------------------------------------------------------------------
Status: Pull Request Sent (was: Open)
> out of memory when logging more messages than heap size (surefire issue)
> ------------------------------------------------------------------------
>
> Key: JBTM-2234
> URL: https://issues.jboss.org/browse/JBTM-2234
> Project: JBoss Transaction Manager
> Issue Type: Bug
> Components: Performance Testing
> Affects Versions: 5.0.2
> Environment: JTS testing
> Reporter: Michael Musgrove
> Assignee: Tom Jenkinson
> Priority: Minor
> Fix For: 5.next
>
>
> Running com.hp.mwtests.ts.jts.orbspecific.local.performance.Performance2 on JacORB with about 500000 transactions results in an OOM error because surefire keeps in logs in memory until the test has finished.
> In this particular test jacorb logs messages at INFO level for each transaction resulting in excessive memory requirements. We can't make the heap too large because the default JVM is 32 bit. However, we could fix it by reducing the jacorb log level to WARN.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 9 months
[JBoss JIRA] (JBTM-2234) out of memory when logging more messages than heap size (surefire issue)
by Tom Jenkinson (JIRA)
[ https://issues.jboss.org/browse/JBTM-2234?page=com.atlassian.jira.plugin.... ]
Tom Jenkinson reassigned JBTM-2234:
-----------------------------------
Assignee: Tom Jenkinson (was: Amos Feng)
> out of memory when logging more messages than heap size (surefire issue)
> ------------------------------------------------------------------------
>
> Key: JBTM-2234
> URL: https://issues.jboss.org/browse/JBTM-2234
> Project: JBoss Transaction Manager
> Issue Type: Bug
> Components: Performance Testing
> Affects Versions: 5.0.2
> Environment: JTS testing
> Reporter: Michael Musgrove
> Assignee: Tom Jenkinson
> Priority: Minor
> Fix For: 5.next
>
>
> Running com.hp.mwtests.ts.jts.orbspecific.local.performance.Performance2 on JacORB with about 500000 transactions results in an OOM error because surefire keeps in logs in memory until the test has finished.
> In this particular test jacorb logs messages at INFO level for each transaction resulting in excessive memory requirements. We can't make the heap too large because the default JVM is 32 bit. However, we could fix it by reducing the jacorb log level to WARN.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 9 months
[JBoss JIRA] (JBTM-2620) Introduce narayana-properties.xml and use as as default property file name, change search order of properties file name
by Tom Jenkinson (JIRA)
[ https://issues.jboss.org/browse/JBTM-2620?page=com.atlassian.jira.plugin.... ]
Tom Jenkinson commented on JBTM-2620:
-------------------------------------
Add a WARNING or NOTE in the docs to bring this to the attention of people as much as possible.
> Introduce narayana-properties.xml and use as as default property file name, change search order of properties file name
> -----------------------------------------------------------------------------------------------------------------------
>
> Key: JBTM-2620
> URL: https://issues.jboss.org/browse/JBTM-2620
> Project: JBoss Transaction Manager
> Issue Type: Feature Request
> Components: Configuration
> Reporter: Tom Jenkinson
> Fix For: 6.later
>
>
> With the next Major release of Narayana:
> 1. We introduce a new narayana-properties.xml
> 2. The narayana-jt* jars not override the properties name in their manifest but we still support that facility in case someone else is using it
> 3. We change the search path to look for <user-overridden-value>.xml, narayana-properties.xml, then jbossts-properties.xml and finally arjuna-properties.xml.
>
> When people use the raw jars (org.jboss.narayana.jta.jta for example) then they can then provide the same narayana-properties.xml as they would if they were using the uber jar (example org.jboss.narayana.jta.narayana-jta) without a system property. It should help in a Maven enabled debugger when executing applications running in integration environments like WildFly or Spring where debugging via an uber jar adds an extra layer that makes getting to the real source code harder and code fix cycle slower.
>
> This should not pose too much of a backwards compatibility issue unless the user has multiple config files with different names (arjuna and jbossts) in their path, were only using arjuna.jar and now jbossts-properties.xml was picked up. But for this reason I propose waiting until Narayana 6.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 9 months
[JBoss JIRA] (JBTM-2602) QA suite failure: TestGroup_txcore_lockrecord
by Michael Musgrove (JIRA)
[ https://issues.jboss.org/browse/JBTM-2602?page=com.atlassian.jira.plugin.... ]
Michael Musgrove closed JBTM-2602.
----------------------------------
Resolution: Won't Fix
The only activity in the stack traces (attached) shows Client003 waiting for a commit to finish. It has passed prepare added its log to an an ibm JDBCStore and is now trying to remove the record but it looks like it is waiting to obtain a connection. Two observations:
# why aren't we using connection pools (this looks like a very inefficient way of updating the database)
# the stack trace shows the connection attempt is waiting inside the ibm JDBC driver
Since it looks like a db comms problem and since we have not seen a subsequent failure (a month ago) I am closing the issue as a spurious failure.
> QA suite failure: TestGroup_txcore_lockrecord
> ---------------------------------------------
>
> Key: JBTM-2602
> URL: https://issues.jboss.org/browse/JBTM-2602
> Project: JBoss Transaction Manager
> Issue Type: Bug
> Components: Testing
> Reporter: Gytis Trikleris
> Assignee: Michael Musgrove
> Priority: Minor
> Fix For: 5.next
>
> Attachments: jstack.tar
>
>
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 9 months
[JBoss JIRA] (JBTM-1820) Integrate with Camel to support XA Transaction
by Tom Jenkinson (JIRA)
[ https://issues.jboss.org/browse/JBTM-1820?page=com.atlassian.jira.plugin.... ]
Tom Jenkinson updated JBTM-1820:
--------------------------------
Description:
>From Ning Jiang (njiang(a)redhat.com)
{quote}
Camel is using Spring TransactionTemplates to implement the Transactional Client pattern[1].
As the Spring PlatformTransactionManager cannot manage the multiple resources, we are using the atomikos to show the user how to manage the transactions between JMS and DB resource. It could great if we can replace the atomikos with narayana, then we can promote this example as reference to SA who can sale the solution to the customer.
Another interesting task could be using the narayana JTA wrapper classes to replace the Spring TransactionTemplate in Camel. As we don't want to build out products on top of Spring framework, using narayana could help us to get ride of Spring and introduce the narayana to integration customer.
[1]http://camel.apache.org/transactional-client.html
{quote}
was:
>From Ning Jiang (njiang(a)redhat.com)
{noformat}
Camel is using Spring TransactionTemplates to implement the Transactional Client pattern[1].
As the Spring PlatformTransactionManager cannot manage the multiple resources, we are using the atomikos to show the user how to manage the transactions between JMS and DB resource. It could great if we can replace the atomikos with narayana, then we can promote this example as reference to SA who can sale the solution to the customer.
Another interesting task could be using the narayana JTA wrapper classes to replace the Spring TransactionTemplate in Camel. As we don't want to build out products on top of Spring framework, using narayana could help us to get ride of Spring and introduce the narayana to integration customer.
[1]http://camel.apache.org/transactional-client.html
{noformat}
> Integrate with Camel to support XA Transaction
> ----------------------------------------------
>
> Key: JBTM-1820
> URL: https://issues.jboss.org/browse/JBTM-1820
> Project: JBoss Transaction Manager
> Issue Type: Enhancement
> Components: Application Server Integration
> Reporter: Amos Feng
> Assignee: Amos Feng
> Fix For: 5.later
>
>
> From Ning Jiang (njiang(a)redhat.com)
> {quote}
> Camel is using Spring TransactionTemplates to implement the Transactional Client pattern[1].
> As the Spring PlatformTransactionManager cannot manage the multiple resources, we are using the atomikos to show the user how to manage the transactions between JMS and DB resource. It could great if we can replace the atomikos with narayana, then we can promote this example as reference to SA who can sale the solution to the customer.
> Another interesting task could be using the narayana JTA wrapper classes to replace the Spring TransactionTemplate in Camel. As we don't want to build out products on top of Spring framework, using narayana could help us to get ride of Spring and introduce the narayana to integration customer.
> [1]http://camel.apache.org/transactional-client.html
> {quote}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 9 months