January 2011 - jboss-jira - Jboss List Archives

[JBoss JIRA] Created: (JBAS-8698) Datasource XAExceptions leads to corrupt Transaction Context on thread

by Anders Welen (JIRA)

Datasource XAExceptions leads to corrupt Transaction Context on thread ---------------------------------------------------------------------- Key: JBAS-8698 URL: https://jira.jboss.org/browse/JBAS-8698 Project: JBoss Application Server Issue Type: Bug Security Level: Public (Everyone can see) Components: ClassLoading, Remoting, Transaction Manager Integration (Arjuna) Affects Versions: 6.0.0.CR1, JBossAS-5.1.0.GA, JBossAS-4.2.1.GA Reporter: Anders Welen Assignee: Scott Stark Attachments: TestCase3850.tar When MySQL throws a "com.mysql.jdbc.jdbc2.optional.MysqlXAException" when called from a remote client the server thread doesn't seem to be cleaned up of transaction context data. All calls that reusing the thread will fail with the following exception: org.jboss.util.NestedSQLException: Transaction is not active: tx=TransactionImple < ac, BasicAction: 7f000002:e137:4cf78939:68 status: ActionStatus.COMMITTING >; - nested throwable: (javax.resource.ResourceException: Transaction is not active: tx=TransactionImple < ac, BasicAction: 7f000002:e137:4cf78939:68 status: ActionStatus.COMMITTING >) at org.jboss.resource.adapter.jdbc.WrapperDataSource.getConnection(WrapperDataSource.java:95) at se.redpill.TestCase3850Bean.runTest(TestCase3850Bean.java:22) ... ... ... >From what I can see the "MysqlXAException" (implements XAException) will not be caught in "com.arjuna.ats.internal.jta.resources.arjunacore.XAResourceRecord.java". (Can it be some kind of classloading problem?) As the result the thread will not be cleaned of transaction information and "broken" when reused. This seems only to occur for remote clients (If the client calls within the JVM it seems to work) -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira

14 years, 4 months

3
6
0 / 0

[JBoss JIRA] Created: (JBAS-7965) jta resource recovery problem

by Nicolae Petridean (JIRA)

jta resource recovery problem ----------------------------- Key: JBAS-7965 URL: https://jira.jboss.org/jira/browse/JBAS-7965 Project: JBoss Application Server Issue Type: Bug Security Level: Public (Everyone can see) Components: Transaction Manager (Arjuna) Reporter: Nicolae Petridean Assignee: Jonathan Halliday Priority: Critical Hi all, i noticed that there is some problems with the transaction recovery in JBOSS. When a number of warnings like this : "WARN oggerI18N om.arjuna.ats.internal.jta.resources.arjunacore.norecoveryxa om.arjuna.ats.internal.jta.resources.arjunacore.norecoveryxa Could not find new XAResource to use for recovering non-serializable XAResource" appear , at some time the exceptions mechanism is affected (the exceptions are not thrown anymore). If the application uses timers those are also blocked (the timeouts dont appear anymore), it seems that the transcations that are not finished are blocking the timers. Why aren't those transactions just ended after some specific time ? Or is there another way to deal with the situation ? Thanks in advance, Nicu -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

14 years, 4 months

3
2
0 / 0

[JBoss JIRA] Created: (JBAS-7930) Set the port_range on JGroups stacks to 1

by Brian Stansberry (JIRA)

Set the port_range on JGroups stacks to 1 ----------------------------------------- Key: JBAS-7930 URL: https://jira.jboss.org/jira/browse/JBAS-7930 Project: JBoss Application Server Issue Type: Task Security Level: Public (Everyone can see) Components: Clustering Reporter: Brian Stansberry Assignee: Brian Stansberry Fix For: JBossAS-6.0.0.M4 Lock down the ports. Do this for M4 as it may lead to testsuite troubles on slaves until we identify ports where there aren't conflicts. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

14 years, 4 months

7
12
0 / 0

[JBoss JIRA] Created: (JBAS-8632) Domain interface should include versions

by Heiko Rupp (JIRA)

Domain interface should include versions ---------------------------------------- Key: JBAS-8632 URL: https://jira.jboss.org/browse/JBAS-8632 Project: JBoss Application Server Issue Type: Feature Request Security Level: Public (Everyone can see) Affects Versions: 7.0.0.Alpha1 Reporter: Heiko Rupp The domain interface should for all servers provide the exact version of the server. This should contain also CP and FP tags. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

14 years, 4 months

14
23
0 / 0

[JBoss JIRA] Created: (JBAS-6532) TCLFilter doesn't work in jboss 5 with war's in any documented way

by robert lazarski (JIRA)

TCLFilter doesn't work in jboss 5 with war's in any documented way ------------------------------------------------------------------ Key: JBAS-6532 URL: https://jira.jboss.org/jira/browse/JBAS-6532 Project: JBoss Application Server Issue Type: Bug Security Level: Public (Everyone can see) Components: Logging Affects Versions: JBossAS-5.0.0.GA Environment: jdk 6, linux Reporter: robert lazarski Assignee: Scott M Stark Reading this doc: http://www.jboss.org/community/docs/DOC-12203 Indicates a *-exp.war syntax is needed for TCLFilter war use, but there are no files of that type on my system running jboss 5. I've tried all the possible combinations I can think of, posted the problem to the forum, and the result is always that the file sizes and contents of the log files generated are exactly the same for the different war's, ie, no separated content. Here's my current config: <appender name="penguinLog" class="org.apache.log4j.FileAppender"> <errorHandler class="org.jboss.logging.util.OnlyOnceErrorHandler"></errorHandler> <param name="Append" value="false"/> <param name="File" value="${jboss.server.home.dir}/log/penguinLog.log"/> <layout class="org.apache.log4j.PatternLayout"> <param name="ConversionPattern" value="%d %-5p %c{1} %m%n"/> </layout> <filter class="org.jboss.logging.filter.TCLFilter"> <param name="AcceptOnMatch" value="true"/> <param name="DeployURL" value="penguin"/> </filter> </appender> <appender name="wtfLog" class="org.apache.log4j.FileAppender"> <errorHandler class="org.jboss.logging.util.OnlyOnceErrorHandler"></errorHandler> <param name="Append" value="false"/> <param name="File" value="${jboss.server.home.dir}/log/wtfLog.log"/> <layout class="org.apache.log4j.PatternLayout"> <param name="ConversionPattern" value="%d %-5p %c{1} %m%n"/> </layout> <filter class="org.jboss.logging.filter.TCLFilter"> <param name="AcceptOnMatch" value="true"/> <param name="DeployURL" value="wtf-exp.war"/> </filter> </appender> <root> <appender-ref ref="CONSOLE"/> <appender-ref ref="FILE"/> <appender-ref ref="penguinLog"/> <appender-ref ref="wtfLog"/> </root> -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

14 years, 4 months

7
13
0 / 0

[JBoss JIRA] Created: (JBRULES-2831) The zips should contain a README_DEPENDENCIES.txt file generated by the build

by Geoffrey De Smet (JIRA)

The zips should contain a README_DEPENDENCIES.txt file generated by the build ----------------------------------------------------------------------------- Key: JBRULES-2831 URL: https://issues.jboss.org/browse/JBRULES-2831 Project: Drools Issue Type: Task Security Level: Public (Everyone can see) Affects Versions: 5.1.1.FINAL Reporter: Geoffrey De Smet Assignee: Geoffrey De Smet Priority: Optional Fix For: FUTURE We're removing the current README_DEPENDENCIES.txt file because it contains a lot of incorrect, misleading info. But we'd still like to give the users that file, but correct. The only decent way to keep it correct is to generate it of the build. In theory we could just take the output of mvn dependency:tree but maybe maven has a better report. Until we do that, the users will have to rely on our released poms, which contain correct info. -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira

14 years, 4 months

3
4
0 / 0

[JBoss JIRA] Created: (JBRULES-2823) Sliding window of length type does not accumulate/collect correctly with multiple objects in constraints

by Mary Ellen Bench (JIRA)

Sliding window of length type does not accumulate/collect correctly with multiple objects in constraints -------------------------------------------------------------------------------------------------------- Key: JBRULES-2823 URL: https://jira.jboss.org/browse/JBRULES-2823 Project: Drools Issue Type: Bug Security Level: Public (Everyone can see) Components: All Affects Versions: 5.1.1.FINAL Environment: Windows XP Java Reporter: Mary Ellen Bench Assignee: Mark Proctor When using sliding windows and a constraint that filters by an input object, it does not properly create a window for each constraints, instead one window shared by both rules which leads to undesirable affects (ie a shared sliding window filtered down to less #s). Please also see the drools post: http://drools-java-rules-engine.46999.n3.nabble.com/DROOLS-problem-with-s... It is best to show the rule and output to explain it: Background: "I have been working with sliding windows, and they do not appear to work properly in DROOLS 5.1.1 or I am misunderstanding how they work. My goal is to have the last X number of samples averaged or summed. I've tried two mechanism, the accumulate/from, and the collect, and they both behave similarly wrong (or different than I expect), but this was much easier to follow so I've posted it for help. The way I have the code structured, I receive values for two nodes, 1 and 2 every second or two, which each contain random values. After each value received I pass the CPUReportEvent and fire the rules. The results are bizarre. Sometimes it resets back to 1 count, sometimes it keeps the value to the previous one. It seems to also fire both rules when really only one should've been triggered? Can someone explain the results and how to adjust it to work for my specs? Thanks! I can't see into the accumulate function, so here's the collect function, but they perform identically. " package com.sample import com.sample.DroolsTest.Message; import com.sample.DroolsInput; import com.sample.CPUReportEvent; import com.ComEntity; import java.util.Iterator import java.util.ArrayList declare CPUReportEvent // declare a fact type as an event, default is 'fact' @role( event ) end rule "collect with length window" no-loop true when $comEntity : ComEntity() $list : ArrayList () from collect( CPUReportEvent(comEntity == $comEntity) over window:length(3) ) then System.out.print("Entity " + $comEntity.getName() + " fired of count " + $list.size() + " value"); Double sum = 0.0; Double count = 0.0; for(Iterator it = $list.iterator();it.hasNext();) { CPUReportEvent report = (CPUReportEvent) it.next(); System.out.print(" " + report.getAmount()); sum = sum + report.getAmount(); count = count + 1.0; } if (count > 0.0) { Double avg = (sum / count); System.out.print(" - Sum " + sum + " avg " + avg + " count " + count); } System.out.println(); end RESULTS: Node1 : 7.0 Entity Node2 fired of count 0 value Entity Node1 fired of count 1 value 7.0 - Sum 7.0 avg 7.0 count 1.0 Node2 : 94.0 Entity Node2 fired of count 1 value 94.0 - Sum 94.0 avg 94.0 count 1.0 Node1 : 43.0 Entity Node1 fired of count 2 value 7.0 43.0 - Sum 50.0 avg 25.0 count 2.0 Node2 : 85.0 Entity Node2 fired of count 2 value 94.0 85.0 - Sum 179.0 avg 89.5 count 2.0 Entity Node1 fired of count 1 value 43.0 - Sum 43.0 avg 43.0 count 1.0 Node1 : 88.0 Entity Node2 fired of count 1 value 85.0 - Sum 85.0 avg 85.0 count 1.0 Entity Node1 fired of count 2 value 43.0 88.0 - Sum 131.0 avg 65.5 count 2.0 Node2 : 47.0 Entity Node2 fired of count 2 value 85.0 47.0 - Sum 132.0 avg 66.0 count 2.0 Entity Node1 fired of count 1 value 88.0 - Sum 88.0 avg 88.0 count 1.0 Node1 : 39.0 Entity Node2 fired of count 1 value 47.0 - Sum 47.0 avg 47.0 count 1.0 Entity Node1 fired of count 2 value 88.0 39.0 - Sum 127.0 avg 63.5 count 2.0 Node1 : 0.0 Entity Node1 fired of count 2 value 39.0 0.0 - Sum 39.0 avg 19.5 count 2.0 -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira

14 years, 4 months

10
16
0 / 0

[JBoss JIRA] Created: (JBWEB-160) XNIO Connector

by Remy Maucherat (JIRA)

XNIO Connector -------------- Key: JBWEB-160 URL: https://jira.jboss.org/jira/browse/JBWEB-160 Project: JBoss Web Issue Type: Feature Request Security Level: Public (Everyone can see) Reporter: Remy Maucherat Assignee: Remy Maucherat Experiment with XNIO connector to determine if it makes sense to include one in JBW. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

14 years, 4 months

2
3
0 / 0

[JBoss JIRA] Created: (JBAS-6657) managementView.load() fails to merge ServerInfo, ThreadPool, GlobalRequestProcessor, and Host ManagedObjects

by Ian Springer (JIRA)

managementView.load() fails to merge ServerInfo, ThreadPool, GlobalRequestProcessor, and Host ManagedObjects ------------------------------------------------------------------------------------------------------------ Key: JBAS-6657 URL: https://jira.jboss.org/jira/browse/JBAS-6657 Project: JBoss Application Server Issue Type: Sub-task Security Level: Public (Everyone can see) Components: ProfileService Reporter: Ian Springer Assignee: Scott M Stark Fix For: JBossAS-5.1.0.CR1 These are all MOs that are needed by the Embedded Console. Here's the log output: 10:47:18,464 DEBUG [ProfileServiceFactory] About to load profile via Management View... 10:47:23,964 WARN [AbstractManagedObjectPopulator] Cannot create String name from non-Simple property: ManagedProperty{JNDIName,JNDIName,metaType=SimpleMetaType:java.lang.String}, value=null 10:47:23,980 WARN [AbstractManagedObjectPopulator] Cannot create String name from non-Simple property: ManagedProperty{JNDIName,JNDIName,metaType=SimpleMetaType:java.lang.String}, value=null 10:47:57,870 WARN [ManagementViewImpl] Failed to merged the following runtime ManagedObjects: {jboss.system:type=ServerInfo/jboss.system:type=ServerInfo=ManagedObject{jboss.system:type=ServerInfo}, jboss.web:name=http-127.0.0.1-8080,type=ThreadPool/=ManagedObject{jboss.web:name=http-127.0.0.1-8080,type=ThreadPool}, jboss.web:name=http-127.0.0.1-8080,type=GlobalRequestProcessor/=ManagedObject{jboss.web:name=http-127.0.0.1-8080,type=GlobalRequestProcessor}, jboss.web:host=127.0.0.1,type=Host/=ManagedObject{jboss.web:host=127.0.0.1,type=Host}} 10:48:00,917 DEBUG [ProfileServiceFactory] Loaded profile via Management View in 42453 milliseconds. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

14 years, 5 months

4
3
0 / 0

[JBoss JIRA] Created: (JBAS-8679) Add xml comment support to the domain model

by Jason Greene (JIRA)

Add xml comment support to the domain model ------------------------------------------- Key: JBAS-8679 URL: https://jira.jboss.org/browse/JBAS-8679 Project: JBoss Application Server Issue Type: Task Security Level: Public (Everyone can see) Reporter: Jason Greene Fix For: 7.0.0.Beta1 For usability reasons, we should attach an xml comment to the nearest AbstractModelElement, so that they can be recreated when the model is altered. -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira

14 years, 5 months

4
5
0 / 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira January 2011