[JBoss JIRA] (AS7-5700) WSBAParticipantCompletionTestCase XTS integration test fails intermittently
by Paul Robinson (JIRA)
Paul Robinson created AS7-5700:
----------------------------------
Summary: WSBAParticipantCompletionTestCase XTS integration test fails intermittently
Key: AS7-5700
URL: https://issues.jboss.org/browse/AS7-5700
Project: Application Server 7
Issue Type: Bug
Components: XTS
Reporter: Paul Robinson
Assignee: Paul Robinson
Priority: Minor
Fix For: 7.2.0.Alpha1, 7.1.4.Final (EAP)
When a WSBA participant employs the ParticipantCompletion protocol, it is the responsibility of the participant to notify the coordinator when it has completed its work. This notification is asynchronous.
In the 'WSBAParticipantCompletionTestCase' test, the client invokes the participant's web service who notifies completion just before returning from the invocation. The client then sends a message to the coordinator requesting to close (complete) the activity.
As the "complete" message is asynchronous, we now have a race. If the Client's close message is processed by the coordinator before the participant's "complete" message, then the coordinator cancels the BA as not all participants have completed. This results in the client receiving a TransactionRolledBackException and the completed participant is (eventually) compensated. The outcome is atomic, but a BA that would have otherwise succeeded, is unsuccessful.
In reality we only expect this scenario to happen in the rather artificial scenario where all parties (client, coordinator and participants) are on the same server. It also only seems to happen on very slow machines. Therefore, it's fine to fix the test to prevent this scenario from arising, rather than to somehow change the protocol (without breaking the WS-BA standard) to prevent it.
We have two options, that I can see to fix the test:
1) Byteman Rendezvous. Here we would introduce a dependency on Byteman and write a script that delays the client's close message until all participants' 'complete' messages have been acknowledged by the coordinator. This is probably an over-engineered solution as we would be introducing Byteman, to these tests, for this single case.
2) We add a Thread.sleep(10000) to the test, just before the client sends the 'cloe' message to the coordinator. This is what we did to the XTS tests in the JBossTS project as a stop-gap until we decided how to do it "properly".
I suggest we go with 2) as it is the simplest solution. The extra time added to the test is just 20s as there are only two tests affected by this. In the future, when we have more tests we should reduce this sleep period or consider using another solution (such as Byteman), in order to keep the test duration acceptable.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
11 years, 10 months
[JBoss JIRA] (AS7-6049) Where security services in domain management have a dedicated interface provide a ServiceName factory.
by Darran Lofthouse (JIRA)
Darran Lofthouse created AS7-6049:
-------------------------------------
Summary: Where security services in domain management have a dedicated interface provide a ServiceName factory.
Key: AS7-6049
URL: https://issues.jboss.org/browse/AS7-6049
Project: Application Server 7
Issue Type: Task
Components: Domain Management
Reporter: Darran Lofthouse
Assignee: Darran Lofthouse
Fix For: 7.2.0.Alpha1
Update each of the interfaces with a factory for generating the service name.
{code}
public static class ServiceNameFactory {
public ServiceName createServiceName(final String realmName) {
return null;
}
}
{code}
Strictly speaking these are not currently expected to be used outside the AS codebase but should they be used outside of the domain-management module this will be the recommended way to generate the service names.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
11 years, 10 months
[JBoss JIRA] (AS7-4782) NoSuchMethodError: org.jboss.logmanager.LogContext.getLoggerIfExists
by Juergen Zimmermann (JIRA)
Juergen Zimmermann created AS7-4782:
---------------------------------------
Summary: NoSuchMethodError: org.jboss.logmanager.LogContext.getLoggerIfExists
Key: AS7-4782
URL: https://issues.jboss.org/browse/AS7-4782
Project: Application Server 7
Issue Type: Bug
Components: Logging
Affects Versions: 7.1.2.Final (EAP)
Environment: Compilation: JBossAS 7.1.2.Final checked out from github.com and compiled with JDK 7u4 32-Bit on Win7 64-Bit.
Runtime: JDK 7u4 64-Bit on same Windows box.
Reporter: Juergen Zimmermann
Assignee: James Perkins
I'm running just a simple test which was working fine on JBossAS 7.1.1. Now on 7.1.2 (see description in the Environment section) I'm getting this stacktrace:
java.lang.RuntimeException: Could not create a new instance of class org.jboss.arquillian.test.impl.EventTestRunnerAdaptor see cause.
at org.jboss.arquillian.test.spi.SecurityActions.newInstance(SecurityActions.java:170)
at org.jboss.arquillian.test.spi.TestRunnerAdaptorBuilder.build(TestRunnerAdaptorBuilder.java:52)
at org.jboss.arquillian.junit.Arquillian.run(Arquillian.java:93)
at org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:236)
at org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:134)
at org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:113)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:601)
at org.apache.maven.surefire.util.ReflectionUtils.invokeMethodWithArray(ReflectionUtils.java:189)
at org.apache.maven.surefire.booter.ProviderFactory$ProviderProxy.invoke(ProviderFactory.java:165)
at org.apache.maven.surefire.booter.ProviderFactory.invokeProvider(ProviderFactory.java:85)
at org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:103)
at org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:74)
Caused by: java.lang.reflect.InvocationTargetException
at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:57)
at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
at java.lang.reflect.Constructor.newInstance(Constructor.java:525)
at org.jboss.arquillian.test.spi.SecurityActions.newInstance(SecurityActions.java:166)
... 14 more
Caused by: java.lang.RuntimeException: Could not create a new instance of class org.jboss.arquillian.core.impl.ManagerImpl see cause.
at org.jboss.arquillian.core.spi.SecurityActions.newInstance(SecurityActions.java:157)
at org.jboss.arquillian.core.spi.ManagerBuilder.create(ManagerBuilder.java:77)
at org.jboss.arquillian.test.impl.EventTestRunnerAdaptor.<init>(EventTestRunnerAdaptor.java:55)
... 19 more
Caused by: java.lang.reflect.InvocationTargetException
at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:57)
at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
at java.lang.reflect.Constructor.newInstance(Constructor.java:525)
at org.jboss.arquillian.core.spi.SecurityActions.newInstance(SecurityActions.java:153)
... 21 more
Caused by: java.lang.NoSuchMethodError: org.jboss.logmanager.LogContext.getLoggerIfExists(Ljava/lang/String;)Lorg/jboss/logmanager/Logger;
at org.apache.log4j.JBossLogManagerFacade.updateParents(JBossLogManagerFacade.java:197)
at org.apache.log4j.JBossLogManagerFacade.getLogger(JBossLogManagerFacade.java:145)
at org.apache.log4j.Hierarchy.getLogger(Hierarchy.java:130)
at org.apache.log4j.Hierarchy.getLogger(Hierarchy.java:125)
at org.apache.log4j.LogManager.getLogger(LogManager.java:57)
at org.apache.log4j.Logger.getLogger(Logger.java:35)
at org.jboss.logging.Log4jLogger.<init>(Log4jLogger.java:35)
at org.jboss.logging.Log4jLoggerProvider.getLogger(Log4jLoggerProvider.java:33)
at org.jboss.logging.LoggerProviders.find(LoggerProviders.java:37)
at org.jboss.logging.LoggerProviders.<clinit>(LoggerProviders.java:32)
at org.jboss.logging.Logger.getLogger(Logger.java:2163)
at org.jboss.logging.Logger.getLogger(Logger.java:2188)
at org.jboss.as.arquillian.protocol.jmx.ArquillianServiceDeployer.<clinit>(ArquillianServiceDeployer.java:47)
at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:57)
at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
at java.lang.reflect.Constructor.newInstance(Constructor.java:525)
at org.jboss.arquillian.core.impl.Reflections.createInstance(Reflections.java:128)
at org.jboss.arquillian.core.impl.ManagerImpl.createExtensions(ManagerImpl.java:410)
at org.jboss.arquillian.core.impl.ManagerImpl.fireProcessing(ManagerImpl.java:345)
at org.jboss.arquillian.core.impl.ManagerImpl.<init>(ManagerImpl.java:98)
... 26 more
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
11 years, 10 months
[JBoss JIRA] (JBRULES-3698) Improper parsing of right parenthesis in rule consequence
by Chris Beesley (JIRA)
Chris Beesley created JBRULES-3698:
--------------------------------------
Summary: Improper parsing of right parenthesis in rule consequence
Key: JBRULES-3698
URL: https://issues.jboss.org/browse/JBRULES-3698
Project: Drools
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: drools-core (expert)
Affects Versions: 5.5.0.Final, 5.4.0.Final, 5.2.0.Final
Reporter: Chris Beesley
Assignee: Mark Proctor
The right parenthesis is improperly parsed when creating a new object:
rule "Test Rule"
dialect "mvel"
when
Person()
then
SuggestedAction s = new SuggestedAction("suggest something with ) a paren")
end
This happens any time you use a new object declaration. It appears to blindly use the parenthesis without considering the quote which results in the following error message during rule compile:
[Error: unterminated string literal]
The following syntax compiles without problems:
rule "Test Rule"
dialect "mvel"
when
Person()
then
SuggestedAction sa = new SuggestedAction("Now no parens here")
sa.putValue("RELEVENCE", "with a ) paren ")
System.out.println(“I am a ) paren ”)
end
Using a left parenthesis does not cause an error. Switching to java dialect does not cause the error.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
11 years, 10 months
[JBoss JIRA] (AS7-6053) Reconsider post-boot logging of management operation errors
by Brian Stansberry (JIRA)
Brian Stansberry created AS7-6053:
-------------------------------------
Summary: Reconsider post-boot logging of management operation errors
Key: AS7-6053
URL: https://issues.jboss.org/browse/AS7-6053
Project: Application Server 7
Issue Type: Task
Components: Domain Management
Reporter: Brian Stansberry
Assignee: Brian Stansberry
Fix For: 7.3.0.Alpha1
Currently after boot if there is a failure during a management request we log it at DEBUG or not at all (see AS7-6046 for the not-at-all issue.) The theory is the error is a client request and the proper error reporting is to propagate the error to the client, which we do via the operation response.
We need to consider logging some errors in the server log as well. Some errors can impact that state of the runtime services, and those kinds of errors should not be invisible in the log.
A simple approach to this would be to log an ERROR message if the problem happened after Stage.MODEL. Any problems in Stage.MODEL never escape the data structures (i.e. the copy of the model) associated with the operation's OperationContext, and thus have no impact to anyone other than the caller.
A further refinement to this would be to only report Stage.RUNTIME errors if the operation has taken an action implying mutation of the service container (context.getServiceRegistry(true) or context.removeService(...)).
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
11 years, 10 months
[JBoss JIRA] (JBJCA-922) Guard against lock changes
by Jesper Pedersen (JIRA)
Jesper Pedersen created JBJCA-922:
-------------------------------------
Summary: Guard against lock changes
Key: JBJCA-922
URL: https://issues.jboss.org/browse/JBJCA-922
Project: IronJacamar
Issue Type: Bug
Components: JDBC
Affects Versions: 1.1.0.Beta2, 1.0.13.Final
Reporter: Jesper Pedersen
Assignee: Jesper Pedersen
Fix For: 1.0.14.Final, 1.1.0.Beta3
In BaseManagedConnection::cleanup guard against changes in the lock ownership changes
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
11 years, 10 months
[JBoss JIRA] (JBJCA-914) Support @ArquillianResource
by Jesper Pedersen (JIRA)
Jesper Pedersen created JBJCA-914:
-------------------------------------
Summary: Support @ArquillianResource
Key: JBJCA-914
URL: https://issues.jboss.org/browse/JBJCA-914
Project: IronJacamar
Issue Type: Task
Components: Arquillian
Reporter: Jesper Pedersen
Assignee: Jesper Pedersen
Fix For: 1.1.0.Beta3
Support
{code}
org.jboss.jca.embedded.Embedded
javax.naming.Context
{code}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
11 years, 10 months
[JBoss JIRA] (JBJCA-920) DistributedWorkManagerStatistics
by Jesper Pedersen (JIRA)
Jesper Pedersen created JBJCA-920:
-------------------------------------
Summary: DistributedWorkManagerStatistics
Key: JBJCA-920
URL: https://issues.jboss.org/browse/JBJCA-920
Project: IronJacamar
Issue Type: Task
Components: Core
Reporter: Jesper Pedersen
Assignee: Jesper Pedersen
Fix For: 1.1.0.Beta3
Create a DistributedWorkManagerStatistics component that keeps track of statistics for linked WorkManagers
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
11 years, 10 months