[JBoss JIRA] Created: (AS7-895) Intermittent issues pushing content for deployment "full-replace" to slave host
by Brian Stansberry (JIRA)
Intermittent issues pushing content for deployment "full-replace" to slave host
-------------------------------------------------------------------------------
Key: AS7-895
URL: https://issues.jboss.org/browse/AS7-895
Project: Application Server 7
Issue Type: Bug
Components: Domain Management
Reporter: Brian Stansberry
Assignee: Brian Stansberry
Fix For: 7.0.0.CR1
Intermittently seeing this:
java.lang.AssertionError: "Operation was not applied successfully to any servers"
at org.junit.Assert.fail(Assert.java:91)
at org.jboss.as.test.integration.domain.DomainTestSupport.validateResponse(DomainTestSupport.java:124)
at org.jboss.as.test.integration.domain.DeploymentManagementTestCase.executeOnMaster(DeploymentManagementTestCase.java:718)
at org.jboss.as.test.integration.domain.DeploymentManagementTestCase.testManagedFullReplaceUnmanaged(DeploymentManagementTestCase.java:639)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:44)
at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:15)
at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:41)
at org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:20)
at org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:28)
at org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:31)
at org.junit.runners.BlockJUnit4ClassRunner.runNotIgnored(BlockJUnit4ClassRunner.java:79)
at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:71)
at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:49)
at org.junit.runners.ParentRunner$3.run(ParentRunner.java:193)
at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:52)
at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:191)
at org.junit.runners.ParentRunner.access$000(ParentRunner.java:42)
at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:184)
at org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:28)
at org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:31)
at org.junit.runners.ParentRunner.run(ParentRunner.java:236)
at org.apache.maven.surefire.junit4.JUnit4TestSet.execute(JUnit4TestSet.java:59)
at org.apache.maven.surefire.suite.AbstractDirectoryTestSuite.executeTestSet(AbstractDirectoryTestSuite.java:115)
at org.apache.maven.surefire.suite.AbstractDirectoryTestSuite.execute(AbstractDirectoryTestSuite.java:102)
at org.apache.maven.surefire.Surefire.run(Surefire.java:180)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at org.apache.maven.surefire.booter.SurefireBooter.runSuitesInProcess(SurefireBooter.java:350)
at org.apache.maven.surefire.booter.SurefireBooter.main(SurefireBooter.java:1021)
Standard Output
Reading response from http://127.0.0.1:8080/test/index.html:
Reading response from http://127.0.0.1:8630/test/index.html:
Reading response from http://127.0.0.1:8080/test/index.html:
OK
Reading response from http://127.0.0.1:8630/test/index.html:
OK
Failed response:
{
"outcome" => "failed",
"result" => {"server-groups" => {
"main-server-group" => {
"main-one" => {
"host" => "master",
"response" => {
"outcome" => "success",
"result" => undefined,
"compensating-operation" => {
"operation" => "full-replace-deployment",
"address" => [],
"name" => "test.war",
"content" => [{"hash" => bytes {
0x00, 0xbf, 0x50, 0x4d, 0x4b, 0x51, 0x74, 0x52,
0x3b, 0x21, 0x10, 0x3c, 0x80, 0xe6, 0x8b, 0x86,
0xe1, 0x19, 0x41, 0xf6
}}],
"runtime-name" => "test.war"
}
}
},
"main-three" => {
"host" => "slave",
"response" => {
"outcome" => "failed",
"failure-description" => "No deployment content with hash 00bf504d4b5174523b21103c80e68b86e11941f6 is available in the deployment content repository."
}
}
},
"other-server-group" => {"other-two" => {
"host" => "slave",
"response" => {
"outcome" => "failed",
"failure-description" => "No deployment content with hash 00bf504d4b5174523b21103c80e68b86e11941f6 is available in the deployment content repository."
}
}}
}},
"failure-description" => "Operation was not applied successfully to any servers"
}
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 11 months
[JBoss JIRA] Created: (JBAS-9193) Tighten up the ServerEnvironment and HostControllerEnvironment contracts
by Brian Stansberry (JIRA)
Tighten up the ServerEnvironment and HostControllerEnvironment contracts
------------------------------------------------------------------------
Key: JBAS-9193
URL: https://issues.jboss.org/browse/JBAS-9193
Project: JBoss Application Server
Issue Type: Task
Security Level: Public (Everyone can see)
Components: Domain Management
Reporter: Brian Stansberry
Fix For: 7.0.0.Beta4
Right now the contract/usage of these classes is a bit of a mishmash. The idea was to store state that's read from Main(). But if there's anything in these that can be overridden from standalone.xml, either we should restrict access to that data or make sure that it has the correct value if a change is made via the management API. For example, the server name can come from standalone.xml if the 'name' attribute is set and for sure will come from the HostController in domain mode.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 11 months
[JBoss JIRA] Created: (AS7-1384) Strange state after :reload
by Heiko Rupp (JIRA)
Strange state after :reload
---------------------------
Key: AS7-1384
URL: https://issues.jboss.org/browse/AS7-1384
Project: Application Server 7
Issue Type: Bug
Components: Domain Management
Reporter: Heiko Rupp
Assignee: Brian Stansberry
7.1 snapshot
I did change a socket binding, so reload is needed. Did a /:read-resource
Then :reload
},
"response-headers" => {"process-state" => "reload-required"}
}
[standalone@localhost:9999 /] :reload
{
"outcome" => "success",
"response-headers" => {
"operation-requires-reload" => true,
"process-state" => "reload-required"
}
}
[standalone@localhost:9999 /] :reload
{
"outcome" => "success",
"response-headers" => {
"operation-requires-reload" => true,
"process-state" => "reload-required"
}
}
I think after the reload (which succeeded) the process-state should no longer be "reload needed".
Also
{"result" => } should be defined and not just null.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 11 months
[JBoss JIRA] Created: (JBRULES-3112) Shift operator differs between Java and MVEL
by Wolfgang Laun (JIRA)
Shift operator differs between Java and MVEL
--------------------------------------------
Key: JBRULES-3112
URL: https://issues.jboss.org/browse/JBRULES-3112
Project: Drools
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: drools-compiler (expert)
Affects Versions: 5.2.0.Final
Reporter: Wolfgang Laun
Assignee: Mark Proctor
Priority: Critical
Fix For: 5.3.0.Beta1
The following DRL file can be run without and with "dialect 'mvel'"; in the latter case rules 2 and 4 do not fire, otherwise all 4 rules fire.
*** Using dialect Java ***
test1 1 << 65552 = 10000
test1 1 << 65536 = 1
test1 1 << 65568 = 1
test2 1 << 4294967296 = 1
test2 1 << 65536 = 1
test2 1 << 65552 = 10000
test2 1 << 65568 = 1
test3 1 << 4294967296 = 1
test3 1 << 65536 = 1
test3 1 << 65552 = 10000
test4 1 << 65552 = 10000
test4 1 << 65536 = 1
*** Using dialect MVEL ***
test1 1 << 65552 = 10000
test1 1 << 65536 = 1
test1 1 << 65568 = 1
test3 1 << 4294967296 = 1
test3 1 << 65536 = 1
test3 1 << 65552 = 10000
=== DRL ===
# dialect "mvel"
rule kickOff
when
then
insert( Integer.valueOf( 1 ) );
insert( Long.valueOf( 1 ) );
insert( Integer.valueOf( 65552 ) ); // 0x10010
insert( Long.valueOf( 65552 ) );
insert( Integer.valueOf( 65568 ) ); // 0x10020
insert( Long.valueOf( 65568 ) );
insert( Integer.valueOf( 65536 ) ); // 0x10000
insert( Long.valueOf( 65536L ) );
insert( Long.valueOf( 4294967296L ) ); // 0x100000000L
end
rule test1
salience -1
when
$a: Integer( $one: intValue == 1 )
$b: Integer( $shift: intValue )
$c: Integer( $i: intValue, intValue == ($one << $shift ) )
then
System.out.println( "test1 " + $a + " << " + $b + " = " + Integer.toHexString( $c ) );
end
rule test2
salience -2
when
$a: Integer( $one: intValue == 1 )
$b: Long ( $shift: longValue )
$c: Integer( $i: intValue, intValue == ($one << $shift ) )
then
System.out.println( "test2 " + $a + " << " + $b + " = " + Integer.toHexString( $c ) );
end
rule test3
salience -3
when
$a: Long ( $one: longValue == 1 )
$b: Long ( $shift: longValue )
$c: Integer( $i: intValue, intValue == ($one << $shift ) )
then
System.out.println( "test3 " + $a + " << " + $b + " = " + Integer.toHexString( $c ) );
end
rule test4
salience -4
when
$a: Long ( $one: longValue == 1 )
$b: Integer( $shift: intValue )
$c: Integer( $i: intValue, intValue == ($one << $shift ) )
then
System.out.println( "test4 " + $a + " << " + $b + " = " + Integer.toHexString( $c ) );
end
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 11 months
[JBoss JIRA] Created: (JBAS-9113) Verify consistent handling of default values and resolved expressions when populating the domain model.
by Darran Lofthouse (JIRA)
Verify consistent handling of default values and resolved expressions when populating the domain model.
-------------------------------------------------------------------------------------------------------
Key: JBAS-9113
URL: https://issues.jboss.org/browse/JBAS-9113
Project: JBoss Application Server
Issue Type: Task
Security Level: Public (Everyone can see)
Components: Domain Management
Reporter: Darran Lofthouse
Fix For: 7.0.0.CR1
On reading the descriptors and executing the operations care needs to be taken to ensure either default values or resolved expressions are not transferred into the domain model - the consequence of this is that when the descriptors are re-written if these values are present in the model they are written as is loosing any default handling / expression resolving.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 11 months
[JBoss JIRA] Created: (JBRULES-2293) Classpath resources being scanned by ResourceChangeScanner could cause improper resource removal
by Steve Ronderos (JIRA)
Classpath resources being scanned by ResourceChangeScanner could cause improper resource removal
------------------------------------------------------------------------------------------------
Key: JBRULES-2293
URL: https://jira.jboss.org/jira/browse/JBRULES-2293
Project: Drools
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: drools-core
Affects Versions: 5.0.1.FINAL
Environment: Windows XP
Java 5
Running in Oracle OC4J 10.1.3.2
Reporter: Steve Ronderos
Assignee: Mark Proctor
I encountered an issue today with my KnowledgeAgent removing resources from its RuleBase shortly after creating it. I have the ResourceChangeScanner running in my application.
I tracked the issue back to the scan() method in ResourceChangeScannerImpl. It appears that the method is trying to identify resources that are no longer available and remove them from both the RuleBase and future scans. To do this it is checking lastModified on the resource and on a result of 0 removing the resource. The resources that I configured in my change-set definitely still exist, but due to URL handler implementation provided by my classloader, getLastModified always returns 0. (The resource I'm retrieving is coming from a jar that is in my application's classpath and the URL handler implementation is oracle.classloader.SharedCodeSourceURL)
Full Email Group trail: http://www.nabble.com/Issue-with-ResourceChangeScanner-td25792358.html
Michael recommends to never scan classpath resources.
--
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
12 years, 11 months
[JBoss JIRA] Created: (JBAS-9349) Server startup message on console goes missing if a deployment fails during server startup
by jaikiran pai (JIRA)
Server startup message on console goes missing if a deployment fails during server startup
------------------------------------------------------------------------------------------
Key: JBAS-9349
URL: https://issues.jboss.org/browse/JBAS-9349
Project: JBoss Application Server
Issue Type: Bug
Security Level: Public (Everyone can see)
Environment: AS7 upstream dated April 19 2011
Reporter: jaikiran pai
Priority: Minor
Fix For: 7.0.0.Beta3
I placed a failing deployment (picked the .ear from JBAS-9261) in the standalone/deployments folder and started the standalone server. The server picked up the deployment during startup and threw a service missing dependency error but *did not* show the usual server started in xxx ms message. Here's the entire log:
{code}
14:02:49,540 INFO [org.jboss.as.deployment] (MSC service thread 1-4) Started FileSystemDeploymentService for directory /NotBackedUp/jpai/business/jboss/wc/jbossas/as7/jboss-as/build/target/jboss-7.0.0.Beta3-SNAPSHOT/standalone/deployments
14:02:49,592 INFO [org.jboss.as.jmx.JMXConnectorService] (MSC service thread 1-1) Starting remote JMX connector
14:02:49,633 INFO [org.jboss.as.server.deployment] (DeploymentScanner-threads - 1) Content added at location /NotBackedUp/jpai/business/jboss/wc/jbossas/as7/jboss-as/build/target/jboss-7.0.0.Beta3-SNAPSHOT/standalone/data/content/43/79aa12f1960aa376bf9cb259576498616f5a7c/content
14:02:49,636 INFO [org.jboss.remoting] (MSC service thread 1-4) JBoss Remoting version 3.1.0.Beta2
14:02:49,712 INFO [org.apache.catalina.core.AprLifecycleListener] (MSC service thread 1-2) The Apache Tomcat Native library which allows optimal performance in production environments was not found on the java.library.path: /opt/Java/SunJava-6/jdk1.6.0_21/jre/lib/i386/server:/opt/Java/SunJava-6/jdk1.6.0_21/jre/lib/i386:/opt/Java/SunJava-6/jdk1.6.0_21/jre/../lib/i386:/usr/java/packages/lib/i386:/lib:/usr/lib
14:02:49,879 INFO [org.jboss.as.server.deployment] (MSC service thread 1-2) Starting deployment of "Stateless.ear"
14:02:49,883 INFO [org.hornetq.core.server.impl.HornetQServerImpl] (MSC service thread 1-3) live server is starting..
14:02:49,980 WARN [org.jboss.vfs] (MSC service thread 1-1) VFS was unable to set the URLStreamHandlerFactory. This will have unpredictable results
14:02:50,022 INFO [org.apache.coyote.http11.Http11Protocol] (MSC service thread 1-2) Starting Coyote HTTP/1.1 on http-localhost-127.0.0.1-8080
14:02:50,114 INFO [org.jboss.as.connector] (MSC service thread 1-4) Starting JCA Subsystem (JBoss IronJacamar 1.0.0.Beta5)
14:02:50,123 INFO [org.jboss.as.server.deployment] (MSC service thread 1-1) Starting deployment of "StatelessWeb.war"
14:02:50,132 INFO [org.jboss.as.server.deployment] (MSC service thread 1-4) Starting deployment of "StatelessEJB.jar"
14:02:50,134 INFO [org.jboss.as.server.deployment] (MSC service thread 1-4) Starting deployment of "StatelessClient.jar"
14:02:50,145 WARN [org.jboss.as.server.deployment] (MSC service thread 1-1) Class Path entry StatelessEJB.jar in "/content/Stateless.ear/StatelessClient.jar" does not point to a valid jar for a Class-Path reference.
14:02:50,221 INFO [org.jboss.as.connector.subsystems.datasources] (MSC service thread 1-1) Bound JDBC Data-source [java:/H2DS]
14:02:50,435 INFO [org.hornetq.core.remoting.impl.netty.NettyAcceptor] (MSC service thread 1-3) Started Netty Acceptor version 3.2.1.Final-r2319 localhost:5455 for CORE protocol
14:02:50,436 INFO [org.hornetq.core.remoting.impl.netty.NettyAcceptor] (MSC service thread 1-3) Started Netty Acceptor version 3.2.1.Final-r2319 localhost:5445 for CORE protocol
14:02:50,438 INFO [org.hornetq.core.server.impl.HornetQServerImpl] (MSC service thread 1-3) HornetQ Server version 2.1.2.Final (Colmeia, 120) started
14:02:50,480 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-3) MSC00001: Failed to start service jboss.deployment.subunit."Stateless.ear"."StatelessWeb.war".INSTALL: org.jboss.msc.service.StartException in service jboss.deployment.subunit."Stateless.ear"."StatelessWeb.war".INSTALL: Failed to process phase INSTALL of subdeployment "StatelessWeb.war" of deployment "Stateless.ear"
at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:108)
at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1675)
at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886) [:1.6.0_21]
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) [:1.6.0_21]
at java.lang.Thread.run(Thread.java:619) [:1.6.0_21]
Caused by: java.lang.IllegalArgumentException: Cannot find source service for lookup name: KeksLocal
at org.jboss.as.ee.component.LookupBindingSourceDescription.<init>(LookupBindingSourceDescription.java:73)
at org.jboss.as.ejb3.deployment.processors.EjbRefProcessor.processDescriptorEntries(EjbRefProcessor.java:99)
at org.jboss.as.ee.component.AbstractDeploymentDescriptorBindingsProcessor.deploy(AbstractDeploymentDescriptorBindingsProcessor.java:57)
at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:102)
... 4 more
14:02:50,661 INFO [org.jboss.as.server] (MSC service thread 1-1) Service status report
New missing/unsatisfied dependencies:
service jboss.naming.context.java.module.Stateless.StatelessWeb (missing)
Services which failed to start:
service jboss.deployment.subunit."Stateless.ear"."StatelessWeb.war".INSTALL: org.jboss.msc.service.StartException in service jboss.deployment.subunit."Stateless.ear"."StatelessWeb.war".INSTALL: Failed to process phase INSTALL of subdeployment "StatelessWeb.war" of deployment "Stateless.ear"
{code}
Removing the failing deployment and restarting the server shows the server startup message:
{code}
14:08:33,603 INFO [org.jboss.as] (MSC service thread 1-2) JBoss AS 7.0.0.Beta3-SNAPSHOT "TBD" started in 3328ms - Started 99 of 123 services (24 services are passive or on-demand)
{code}
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 11 months