[JBoss JIRA] Created: (AS7-1850) Domain - system properties for log, data, temp aren't reflected
by Rostislav Svoboda (JIRA)
Domain - system properties for log, data, temp aren't reflected
---------------------------------------------------------------
Key: AS7-1850
URL: https://issues.jboss.org/browse/AS7-1850
Project: Application Server 7
Issue Type: Bug
Components: Domain Management, Scripts
Reporter: Rostislav Svoboda
Assignee: Brian Stansberry
Fix For: 7.1.0.Alpha1
Some properties defined in https://docs.jboss.org/author/display/AS71/Command+line+parameters and in {{HostControllerEnvironment}} (org.jboss.as.host.controller) aren't reflected by current implementation.
Affected properties:
- jboss.domain.data.dir
- jboss.domain.log.dir
- jboss.domain.temp.dir
In my scenario only jboss.domain.deployment.dir and jboss.domain.servers.dir were reflected.
Structure for host-controller and process-controller logs + structure for data, log, tmp directories for server instances can't be mapped to that three properties. Maybe these properties could work:
- jboss.domain.host-controller.log.dir
- jboss.domain.process-controller.log.dir
- jboss.domain.server-one.data.dir
- jboss.domain.server-one.log.dir
- jboss.domain.server-one.temp.dir
- jboss.domain.server-xy.data.dir
- jboss.domain.server-xy.log.dir
- jboss.domain.server-xy.temp.dir
Reproducer of my steps:
{code}
rm -rf xx-data xx-log xx-temp xx-deployment xx-servers
mkdir xx-data xx-log xx-temp xx-deployment xx-servers
bin/domain.sh -Djboss.domain.data.dir=xx-data -Djboss.domain.log.dir=xx-log -Djboss.domain.temp.dir=xx-temp -Djboss.domain.deployment.dir=xx-deployment -Djboss.domain.servers.dir=xx-servers
bin/jboss-admin.sh --connect controller=127.0.0.1 command='deploy /home/rsvoboda/devel/JBQA-5161-scripts-testing/target/props.war --all-server-groups'
bin/jboss-admin.sh --connect controller=127.0.0.1 command='undeploy props.war --all-relevant-server-groups'
ls -al xx-data xx-log xx-temp xx-deployment xx-servers
{code}
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
14 years, 3 months
[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
14 years, 3 months
[JBoss JIRA] (AS7-3178) Memory leak in controller client
by Stuart Douglas (Created) (JIRA)
Memory leak in controller client
--------------------------------
Key: AS7-3178
URL: https://issues.jboss.org/browse/AS7-3178
Project: Application Server 7
Issue Type: Bug
Components: Domain Management
Affects Versions: 7.1.0.CR1b
Reporter: Stuart Douglas
Assignee: Stuart Douglas
Priority: Critical
Fix For: 7.1.0.Final
org.jboss.as.protocol.mgmt.AbstractMessageHandler registers a close handler but does not remove it. This means that every message is retained in memory until the connection is closed. If the messages are large this can result in a significant leak (such as in the CDI TCK, where each message is holding onto the deployment bytes).
--
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
14 years, 3 months
[JBoss JIRA] Created: (AS7-1678) ARQ test runner error stack trace is not intuitive
by Richard Opalka (JIRA)
ARQ test runner error stack trace is not intuitive
--------------------------------------------------
Key: AS7-1678
URL: https://issues.jboss.org/browse/AS7-1678
Project: Application Server 7
Issue Type: Bug
Affects Versions: 7.0.1.Final
Reporter: Richard Opalka
Assignee: Aslak Knutsen
Fix For: 7.0.2.Final
>From the stack trace below it's not clear what's going wrong and how to fix this problem.
I had to include my *TestCase class file in deployed archive to workaround it.
11:04:06,903 ERROR [org.jboss.arquillian.protocol.jmx.JMXMethodExecutor] (main) Failed: org.jboss.as.testsuite.integration.as1675.AS1675TestCase.testEjb3EndpointInjection: java.lang.IllegalStateException: Cannot obtain Arquillian config for: org.jboss.as.testsuite.integration.as1675.AS1675TestCase
at org.jboss.as.arquillian.service.ArquillianService.getArquillianConfig(ArquillianService.java:178)
at org.jboss.as.arquillian.service.ArquillianService.getArquillianConfig(ArquillianService.java:188)
at org.jboss.as.arquillian.service.ArquillianService.access$300(ArquillianService.java:64)
at org.jboss.as.arquillian.service.ArquillianService$ExtendedJMXTestRunner.runTestMethod(ArquillianService.java:199)
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:616)
at com.sun.jmx.mbeanserver.StandardMBeanIntrospector.invokeM2(StandardMBeanIntrospector.java:111)
at com.sun.jmx.mbeanserver.StandardMBeanIntrospector.invokeM2(StandardMBeanIntrospector.java:45)
at com.sun.jmx.mbeanserver.MBeanIntrospector.invokeM(MBeanIntrospector.java:226)
at com.sun.jmx.mbeanserver.PerInterface.invoke(PerInterface.java:138)
at com.sun.jmx.mbeanserver.MBeanSupport.invoke(MBeanSupport.java:251)
at com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.invoke(DefaultMBeanServerInterceptor.java:857)
at com.sun.jmx.mbeanserver.JmxMBeanServer.invoke(JmxMBeanServer.java:795)
at org.jboss.as.jmx.tcl.TcclMBeanServer.invoke(TcclMBeanServer.java:214)
at javax.management.remote.rmi.RMIConnectionImpl.doOperation(RMIConnectionImpl.java:1450)
at javax.management.remote.rmi.RMIConnectionImpl.access$200(RMIConnectionImpl.java:90)
at javax.management.remote.rmi.RMIConnectionImpl$PrivilegedOperation.run(RMIConnectionImpl.java:1285)
at javax.management.remote.rmi.RMIConnectionImpl.doPrivilegedOperation(RMIConnectionImpl.java:1383)
at javax.management.remote.rmi.RMIConnectionImpl.invoke(RMIConnectionImpl.java:807)
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:616)
at sun.rmi.server.UnicastServerRef.dispatch(UnicastServerRef.java:322)
at sun.rmi.transport.Transport$1.run(Transport.java:177)
at java.security.AccessController.doPrivileged(Native Method)
at sun.rmi.transport.Transport.serviceCall(Transport.java:173)
at sun.rmi.transport.tcp.TCPTransport.handleMessages(TCPTransport.java:553)
at sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run0(TCPTransport.java:808)
at sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run(TCPTransport.java:667)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603)
at java.lang.Thread.run(Thread.java:679)
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
14 years, 3 months
[JBoss JIRA] (AS7-3040) IPv6: IP address proccessing in pure IPv6 (only) network stack environment
by Pavel Janousek (Created) (JIRA)
IPv6: IP address proccessing in pure IPv6 (only) network stack environment
--------------------------------------------------------------------------
Key: AS7-3040
URL: https://issues.jboss.org/browse/AS7-3040
Project: Application Server 7
Issue Type: Bug
Components: Server
Affects Versions: 7.1.0.Beta1b
Reporter: Pavel Janousek
Assignee: Jason Greene
Priority: Blocker
Actual implementation of processing IP address (e.g. from XML cfg) as 127.0.0.1 is +totally+ useless in IPv6 environment (it has its own *incompatible* ekvivalent - _::1_). The default behavior of AS7 is IPv6 disabled at all, so user should be forced to *reconfigure* his instance of AS7 to run it in pure IPv6 network stack only (the are also missing some document described this process yet! - AS7-3039).
So one issue is when AS7 instance is bring up with default configuration (distributed standalone.xml), but in an IPv6 network environment available only like:
{code}
bin/standalone.sh -Djava.net.preferIPv4Stack=false
{code}
It uses configured address 127.0.0.1 (default from standalone.xml if key _jboss.bind.address_ isn't defined) as binding point which it could try to use. It is bad and should be avoided, because 127.0.0.1 isn't +valid IPv6 address+, nor allowed IPv6 address format specification (see [RFC 5952|http://tools.ietf.org/html/rfc5952]), and note - IPv4-Compatible IPv6 Address are deprecated (see [RFC 4291 section 2.5.1.1|http://tools.ietf.org/html/rfc4291#section-2.5.5]). Only one possibility is allowed now - IPv4-Mapped IPv6 Address, but it has it's own format and regulary defined address space, also it doesn't make sense to use it in pure IPv6 environment.
*So conclusion - a such address setting (127.0.0.1) in pure IPv6 environment is miss-configuration error at all and starting AS7 instance in this case should only report valid error message about what happens and end itself, not trying to do with a such address format anything - nor convert to other address format, nor use its own inside logic (convert to ::ffff:<IPv4>) etc..*
This error relates to other one - produced log contains nonsense messages as:{code}12:59:31,222 INFO [org.jboss.as.remoting] (MSC service thread 1-2) Listening on localhost.localdomain/127.0.0.1:4447
{code} even though it is bound and listening only on _::ffff:127.0.0.1:4447_.
--
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
14 years, 3 months
[JBoss JIRA] (AS7-3437) JMS clients - Remote JNDI lookup does not work in EAP6/AS7
by Jason Greene (JIRA)
[ https://issues.jboss.org/browse/AS7-3437?page=com.atlassian.jira.plugin.s... ]
Jason Greene closed AS7-3437.
-----------------------------
Labels: (was: eap6_prd_req)
Fix Version/s: No Release
(was: 7.1.0.Final)
Resolution: Duplicate Issue
> JMS clients - Remote JNDI lookup does not work in EAP6/AS7
> ----------------------------------------------------------
>
> Key: AS7-3437
> URL: https://issues.jboss.org/browse/AS7-3437
> Project: Application Server 7
> Issue Type: Feature Request
> Reporter: Miroslav Novak
> Assignee: David Lloyd
> Priority: Blocker
> Fix For: No Release
>
>
> EAP6/AS7 have not yet implemented remote jndi lookups. This feature is important for standalone jms clients to work and also ensure backward compatibility with EAP5/AS6 applications. Following piece of code should work without change:
> Properties properties = new Properties();
> properties.setProperty("java.naming.factory.initial", "org.jnp.interfaces.NamingContextFactory");
> properties.setProperty("java.naming.provider.url", "jnp://server_hostname:1099");
> properties.setProperty("java.naming.factory.url.pkgs", "org.jnp.interfaces.NamingContextFactory");
> context = new InitialContext(properties);
> ConnectionFactory cf = (ConnectionFactory) context.lookup("RemoteConnectionFactory");
> con = cf.createConnection();
> session = con.createSession(false, Session.CLIENT_ACKNOWLEDGE);
> Queue queue = (Queue) context.lookup("/queue/test");
> For now there is a workaround but it's not suitable for us. Example code:
> https://github.com/jbossas/jboss-as/tree/master/demos/legacy/src/main/jav...
> There are AS7 jiras related to this missing feature which are closed as rejected/duplicated. In AS7-1338 J. Green explains that some kind of remote jndi functionality will be in AS 7.1 (as part of the EE full profile). Unfortunately AS 7.1 is still missing this feature.
--
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
14 years, 3 months